http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
--- Comment #47 from Uros Bizjak <ubizjak at gmail dot com> 2013-01-08 19:23:41 UTC --- (In reply to comment #44) > Can't reproduce on x86_64-linux with current trunk at -O3 -g -ffast-math, both > with LRA and when LRA is disabled. From what I understood, this bug used to > be > present on darwin, but went away two years ago, then it got reopened for > x86_64-linux in July and apparently doesn't reproduce anymore either. So, is > this broken anywhere now? Sorry for late answer, the NaN is still generated with current mainline, as can be proved with: "-g -O3 -ffast-math -ffpe-trap=invalid" $ ./a.out MAIN : FIN S00002 MAIN : FIN S00001 MAIN : FIN S00011 MAIN : FIN S00022 Program received signal SIGFPE: Floating-point exception - erroneous arithmetic operation. Backtrace for this error: #0 0x7F9A9AF66FD7 #1 0x7F9A9AF675A4 #2 0x346B2359AF #3 0x40AAA6 in s00017_ at doduc.f90:1852 #4 0x41B9E9 in MAIN__ at doduc.f90:186 Floating point exception *However*, --ffast-math implies -fno-signaling-nans, and this contradicts with -ffpe-trap=invalid. Going a bit further: "-g -O3 -ffast-math -fsignaling-nans -ffpe-trap=invalid" works as expected, without FP exceptions. So, as far as I'm concerned, "--fast-math -ffpe-trap=invalid" combination of options (and the whole issue with NaNs on x86_64 as dubiously raised in comment #34) is invalid.
