Date:	Fri, 11 Nov 1994 16:59:05 +0100
From:	root <root AT falcon DOT fat DOT bme DOT hu>
To:	djgpp AT sun DOT soe DOT clarkson DOT edu
Subject:	DJGPP & MATH

As I read much about floating point errors in GCC 1.12 or 1.11 nowdays,
maybe it is worthwile to report about my experinences.
I was given a C program written by Steven Pemberton (steven.cwi.nl)
which tests the capabilities of a C compiler. The copy I have is of Ver. 4.2.
I compiled and run it succesfully with TURBO C and C++ (Version 1.0 -2.0),
BORLAND C++ (Version 3.0, 3.1 and 4.0) compilers AND with DJGPP 1.09.
I switched on DJGPP 1.11 maint 5 a while ago and now it occured to me that
I gave the new compiler a test, and found out that it just crashes as you see:

	go32 version 1.11.maint5 Copyright (C) 1993 DJ Delorie
	Produced by config version 4.2, CWI, Amsterdam
	Compiler claims to be ANSI C level 1
	
	Char = 8 bits, signed
	Short=16 int=32 long=32 float=32 double=64 bits
	Long double=96 bits
	Char pointers = 32 bits
	Int pointers = 32 bits
	Alignments used for char=1 short=2 int=4 long=4
	Character order:
	    short: BA
	    int:   DCBA
	    long:  DCBA
	Strings are shared
	Overflow of a short does not generate a trap
	Maximum short = 32767 (= 2**15-1)
	Minimum short = -32768
	Overflow of an int does not generate a trap
	Maximum int = 2147483647 (= 2**31-1)
	Minimum int = -2147483648
	Overflow of a long does not generate a trap
	Maximum long = 2147483647 (= 2**31-1)
	Minimum long = -2147483648
	
	PROPERTIES OF FLOAT:
	Base = 2
	Significant base digits = 24 (= at least 6 decimal digits)
	Arithmetic rounds towards nearest
	   Tie breaking rounds to even
	Smallest x such that 1.0-base**x != 1.0 = -24
	Smallest x such that 1.0-x != 1.0 = 0.00000000e+00
	Floating Point exception at eip=3274
	eax=00000000 ebx=00000006 ecx=0000002e edx=00051c30 esi=00000000 edi=00000000
	ebp=00051c8c esp=00051c58 cs=b7 ds=af es=af fs=af gs=c7 ss=bf cr2=00001fdb
	Call frame traceback EIPs:
	  0x00003274
	  0x00004a5f
	  0x00001645

I compiled it with a simple command line as I did it before:
	GCC -o testccom testccom.c -lm

I had to change the source a little bit though: I renamed a function called
'setmode' to 'Setmode' as it duplicated 'setmode' in the standard library

When compiled with -g symify gave me the following:

	  0x00003270   _fCheck+216, line 1651 of testccom.c
	  0x00004a5b   _fprop+3075, line 1907 of testccom.c
	  0x00001645   _main+597, line 572 of testccom.c

Actualy the offending line is: 
				if (new != 0.0) {

I know this program stretches the compiler to the limits, so such behaviour are
to be expected, but there wasn't any problems with  version 1.09.

Under Linux (with GCC ver 2.5.8) the same program run i without any problems 
although it warns about GCC not using a IEEE double number:

	
	PROPERTIES OF LONG DOUBLE:
	Base = 2
	Significant base digits = 64 (= at least 18 decimal digits)
	Arithmetic rounds towards nearest
	   Tie breaking rounds to even
	Smallest x such that 1.0-base**x != 1.0 = -64
	Smallest x such that 1.0-x != 1.0 = -0.00000000000000000000e+00
	
	*** WARNING: sscanf returned an unusable number
	    scanning: -0.00000000000000000000e+00 with format: %Le

	Smallest x such that 1.0+base**x != 1.0 = -63
	Smallest x such that 1.0+x != 1.0 = -4.94065645841246544177e-324
	
	*** WARNING: sscanf returned an unusable number
	    scanning: -4.94065645841246544177e-324 with format: %Le
	
	Number of bits used for exponent = 15
	Minimum normalised exponent = -16381
	Minimum normalised positive number = -0.00000000000000000000e+00
	
	*** WARNING: sscanf returned an unusable number
	    scanning: -0.00000000000000000000e+00 with format: %Le
	
	The smallest numbers are not kept normalised
	Smallest unnormalised positive number = 4.94065645841246544177e-324
	
	*** WARNING: sscanf returned an unusable number
	    scanning: 4.94065645841246544177e-324 with format: %Le
	
	Long double overflow generates a trap
	Maximum exponent = 16384
	Maximum number = -NaN
	
	*** WARNING: sscanf returned an unusable number
	    scanning: -NaN with format: %Le
	
	
	*** Something fishy here!
	    Exponent size + mantissa size doesn't match with the size of a long double!
	
	It doesn't look like IEEE format
	
	Float expressions are evaluated in long double precision
	Double expressions are evaluated in long double precision
	Long double expressions are evaluated in long double precision
	Memory mallocatable ~= 1045499 Kbytes
	
(And again with Version 1.09 of djgpp double and long double 
WERE IEEE numbers...)

I do not attach the TESTCCOM.C program to this letter as it is 
2279 lines long. If there will be enough people interested in it I will post 
it to this list or will try to put it somewhere on the net.

					Andras Solyom
					(solyom AT bmeik DOT eik DOT bme DOT hu)

- Raw text -