gcc floating point bug(?) update + Source

Tue Jan 21 05:00:00 GMT 2003

Hi there,

First I want to apologize for the long post in advance. I ran a few more
checks on various systems with various configurationsm so I can clarify 
my previous posts (i.e. 
http://gcc.gnu.org/ml/gcc-bugs/2003-01/msg01047.html). I attached two
source files to this mail:
(1) invtest.c:
      This is an excerpt from the original software where the bug(*) first
      was discovered.
(2) tstbug.c:
      When I tried to isolate the error in my software I first wrote this
      little program. Though I wasn't able to reproduce the exact same
      behaviour, but some other oddities showed up.

Furthermore there is a "Makefile" included which makes it easier to run
a few test cases on (1) and a bash-script "machtest" which runs the
checks and displays the results.

I asked to others to verify this and this is what they replied:
(A) (he also wrote the machtest script)

  > Hi!
  >
  > my results are (Debian system with kernel 2.4.20):
  >
  > - with gcc-2.95.4 and gcc-3.2 (GCC) 3.2.1 20020924 (Debian prerelease)
  > the make ok_x run flawlessly (as far as I can tell...), they have always
  > the same results, the same goes for the okbroke ones, except that they
  > have inverted results from the ok ones
  > rhe "broken" runs seem to give always the same result for each run, but
  > it puts out much more lines (for each matrixToUpper/Lower there are 5
  > extra lines "corrections of ... via ... at ...: 19 (or 18)", also the
  > Iterations are with 113 or 114 much higher than the 0/1 ones of the
ok runs
  >
  > - with gcc 3.0.4:
  > ok10 gives the same results as the broken ones above, the broken runs
  > with gcc-3 result in:
  > broken3: gcc-3.0 -Wall -lm -D_PRINTPROGRESS_ -O2 -finline-functions -o
  > invtest invtest.c
  > corrections of +0.000000000000E+00 via +NAN at 1,0: 1
  > Transform error!
  > Transform error!
  >
  > - with g++ instead of gcc (2.95.4) the okbroken runs have the same
  > results as the broken runs and the broken runs with gcc

(B)
  > Error does not occur on:
  >  FreeBSD 4.6.2-RELEASE, gcc version 2.95.3 20010315 (release)
[FreeBSD] (make broken1)
  >  FreeBSD 4.6.2-RELEASE, gcc 3.2 (make broken2, make broken3)
  >  SunOS 5.8 Generic_108528-13 sun4u sparc, gcc version 3.2, Thread
model: posix  (make broken[1,2,3])
  >
  > Error does occur on:
  >  Debian Woody, 2.2.19, gcc version 2.95.4 20011002 (Debian
prerelease) (make broken1)
  >  Gentoo, 2.2.20, gcc version 2.95.3 20010315 (release) (make broken1
using CC2=gcc or CC2=g++)
  > Gentoo, 2.2.20, gcc version 2.95.3 20010315 (release) (make
okbroke[1,2,3] using CC2=g++)
  > Suse, 2.4.18-4GB, gcc version 2.95.3 20010315 (SuSE) (make broken1)

  > I think the possible cause is -fcaller-saves. Try this:
  >   gcc -O1  -fcaller-saves   -Wall -lm -D_PRINTPROGRESS_  -o invtest
invtest.c;./invtest
  >   gcc -O1  -Wall -lm -D_PRINTPROGRESS_  -o invtest invtest.c;./invtest
(Here I think that he actually meant to sav "-O2" because then the
results differ)

(B) also wrote about some prototype missing warning messages that
neither (A) nor me could reproduce though - maybe it only occurs on a
SUN station...

So all in all the results are:
file (1):
1.) on BSD everything works fine
2.) the "okx" work on every compiler, every configuration, every machine
and OS, exception: ok10 and gcc-3.0.4, but since it's an old version I 
did not really check this
3.) g++ (2.95) breaks the "okbrokex" the same way gcc on Linux breaks
the "brokenx"
4.) when using "-fno-caller-saves" and no "-finline-functions" all -O
switches work fine
5.) when using "-finline-functions" and a -O greater or equal than -O1
it breaks (in the sense of both okbroke and broken)
file (2):
1.) on BSD everything works fine
2.) using gcc (2.95) -O0 produces already a different result (number
2) on the result line than both the others (number 1 and number 3) - 
this may be due to some
less strict precision calculation requirement on linux, I don't know
3.) using gcc (2.95) -O0 and -O1 the 1st and 3rd result are the same
(as they should be)
4.) using gcc (2.95) -O2 the 3rd and 1st result differ (what they
should NOT - after all, the calculations are carried out in the exact
same way)
5.) using gcc-3.2 the last 2 results always differ from the 1st starting 
at -O2, otherwise the 1st and 3rd are always the same and only the 2nd 
differs. It does not seem to be caused by inline-functions - a -O1 
-finline-functions still gives the same results as -O0 or -O1.
I don't understand why - if the precision requirements are less strict 
in gcc-3.2, why is the first result always the same and not equal to the 
3rd?

Note:
The results of gcc-2.95.3, gcc-2.95.4 and gcc-2.96 were always exactly 
the same.

Conclusion:
There seems to be some problem in the implementation of caller-saves and
inline-functions on non-BSD systems. So in case I don't misunderstand
the specification (and the strange results of file (2) make me doubt
that) this could be a very critical error IMHO. After all, a scenario
could be like this:
Someone writes a program. Checks test cases and real data with it
without using any optimization. After extensive checking and testing he
switches on optimizations that are supposed to be stable (like -O1 and
-O2) and expects it to work. Or maybe he even checked it on a BSD system
   (where it works) and than expects it to work on the other systems the
same way (it's gcc, after all!).
It would really be nice if someone could help me out with this. Am I
overlooking something or might this really be a bug in gcc?

Thanks in advance!

-------------------------------------------------------------------------
* I call this weird behaviour a "bug", but if I have some serious mis-
understanding of gcc, it's parameters or it's simply a bug in my program
which I fail to see just substitute "complete and utter misunderstand-
ing" for it ;-)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: gcc-bug-report.tgz
Type: application/x-compressed
Size: 3395 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc-help/attachments/20030121/28d0ec35/attachment.bin>