This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug fortran/53778] bad code (delivering NaN instead of proper result) with -foptimize-sibling-calls
- From: "dominiq at lps dot ens.fr" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Wed, 27 Jun 2012 13:44:43 +0000
- Subject: [Bug fortran/53778] bad code (delivering NaN instead of proper result) with -foptimize-sibling-calls
- Auto-submitted: auto-generated
- References: <bug-53778-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53778
--- Comment #4 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2012-06-27 13:44:43 UTC ---
I have played a little with the attached test (I had to comment out 'use
textdata' and 'use lapack'. On x86_64-apple-darwin10, I do not get any NaN with
4.6.3, 4.7.1, or trunk with the default flag. However if I add
'-finit-real=snan -ffpe-trap=invalid,zero,overflow' to the flags, the line
single q: 1.6614401858304297 NaN
NaN
(for '-finit-real=nan') is replaced with
Floating exception
So it seems likely that the code is using uninitialized variable(s) (not
detected by -Wuninitialized). Note that one property of NaN is that they
"propagate", i.e., they can be detected quite far away from the point where
they are generated.
It looks like the bug is in the code rather than in gfortran.