Bug 19469 - wrong code on i486 compiling with f77 -fno-automatic -O1
Summary: wrong code on i486 compiling with f77 -fno-automatic -O1
Status: RESOLVED DUPLICATE of bug 323
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 3.3.6
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
Keywords: wrong-code
Depends on:
Reported: 2005-01-16 16:33 UTC by Debian GCC Maintainers
Modified: 2005-07-23 22:49 UTC (History)
3 users (show)

See Also:
Host: i486-linux
Known to work:
Known to fail: 2.95.4 3.3.5 3.4.3
Last reconfirmed:

test case (3.37 KB, application/gzip)
2005-01-16 16:35 UTC, Debian GCC Maintainers

Note You need to log in before you can comment on or make changes to this bug.
Description Debian GCC Maintainers 2005-01-16 16:33:35 UTC
[forwarded from http://bugs.debian.org/290438]

seen with 2.95.4, 3.3.6, 3.4.3. I'm unable to reproduce the ICE mentioned below.
The libraries mentioned are from cernlib 2004.11.04.


The bug submitter writes:

I have tracked down a bug report I was sent about libmathlib1 to a 
compiler optimization problem in g77 on i386.  Please see the attached 
file for a test case.  (Gunzip and un-tar it, cd into the resulting 
directory, and run "make" on a system with g77, make, libmathlib1-dev, 
libpacklib1-dev, and libkernlib1-dev packages installed.) 
The test case calculates the value of the triple integral of 
(sin(x)*sin(y)*sin(z))^2 with all three limits going from 1.d-8 to 
pi, whose value is equal to a tiny amount less than (pi^3)/8.  (The 
setup is done in test.f and the main work in radmul.f, which comes from 
Cernlib source code.)  The program prints out the numerical value of the 
integral, percent estimated error, number of iterations, and returned 
error flag. 
When the file radmul.f is compiled with g77 -O0 -fno-automatic flags, or 
just with -O1 flag, the following correct output is produced: 
 calling dadmul 
 I=  3.87578459+-  7.11202394E-12% 495 evals error        0 
When the flags -fno-automatic -O1 (or higher) are given, the output is 
quite wrong: 
 calling dadmul 
 I=  42336.3332+-  2.45015127% 999999 evals error        1 
If lines 10 and 11 of test.f are changed to set A(1) and A(2) [the lower 
bounds of integration] to 0.d0 instead of 1.d-8, the output with 
-fno-automatic -O1 is no longer outrageously large, but it still has a 
lot of error: 
 calling dadmul 
 I=  3.87588078+-  0.000990792397% 18315 evals error        0 
The above behavior is that of g77-3.3 and g77-2.95.  g77-3.4 does even 
worse.  It produces the same result as g77-3.3 for the -fno-automatic -O1 
case.  Furthermore, when g77-3.4 is called with only -O1 (no 
-fno-automatic flag), the resulting program segfaults.  (Run the 
attached testcase with "make F77=g77-3.4" to see.) 
For the three arches I've tested, these problems occur only on i386, not 
on powerpc nor on sparc. 
You may wish to clone this report to g77-3.4 and g77-2.95. 
I owe thanks to Eduardo A. Menendez Proupin for finding this bug, 
tracking down which Cernlib source code file it came from, and composing 
the test case.
Comment 1 Debian GCC Maintainers 2005-01-16 16:35:17 UTC
Created attachment 7966 [details]
test case
Comment 2 Andrew Pinski 2005-01-16 16:36:18 UTC
Hmm, this really sounds like PR 323. (I would have them look at that PR and make sure they try out 
Comment 3 Andrew Pinski 2005-01-16 16:39:54 UTC
Also since this depends on a library, we really need a self contained example.

I still think -ffloat-store will "fix" their problem.  If it does then it is a dup of PR 323.
Comment 4 Debian GCC Maintainers 2005-01-16 16:59:18 UTC
g77 -O1 -ffloat-store work for 3.3.4, but not for 3.4.3.
Comment 5 Kevin B. McCarty 2005-01-17 14:33:08 UTC
Hi, I'm the original submitter of the bug to Debian's BTS.

On my system, as you predicted, adding -ffloat-store to the options used in
compiling radmul.f to object code solves all the problems with g77 3.3 and 3.4.
 (I haven't re-tested 2.95.)  This includes the g77-3.4 segfault.  That is, the
executable that has radmul.f compiled with "g77-3.4 -c -O1" segfaults, but with
"g77-3.4 -c -O1 -ffloat-store" it exhibits the expected behavior.

I will try to have a self-contained test case within a week or so (time
permitting) so you can check whether this really is the same thing as PR 323.
Comment 6 Andrew Pinski 2005-01-17 15:39:58 UTC
Since -ffloat-store makes it work, then this is a dup of bug 323.

*** This bug has been marked as a duplicate of 323 ***