Date: Fri, 11 Nov 1994 16:59:05 +0100 From: root 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)