[Bug fortran/53778] bad code (delivering NaN instead of proper result) with -foptimize-sibling-calls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53778 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus 2012-06-26 12:29:30 UTC --- (In reply to comment #0) > I have a function in my Fortran code base that looks like this: [...] Can you create a full example? It is usually not easy to debug such issues without having a handle to a full example. Additionally, the code shown does typically not contain the full information. For instance, the issue might be due to inlining - but then it depends also on how and where it is inlined. > If this issue is already known and something along that fixed (in 4.7, > perhaps?), that would be a nice surprise. Well, the easiest is that you try it yourself as you have the full source code. Unofficial builds of 4.7 and 4.8 are available at http://gcc.gnu.org/wiki/GFortranBinaries Having said that, I am not aware of any recent fix which could have directly fixed that, nor do I know of any issue related to -foptimize-sibling-calls which still affects the fairly recent 4.6.3.
[Bug fortran/53778] bad code (delivering NaN instead of proper result) with -foptimize-sibling-calls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53778 --- Comment #2 from Thomas Orgis 2012-06-27 08:58:57 UTC --- Created attachment 27710 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27710 tarball with complete source to reproduce the issue Ok, then, I feared as much. After taking too much time off the work I get actually paid for (did I say that scientific programming sucks?) ... here is a tarball that reproduces the issue for me and is hopefully small enough to serve as a starting point. It is a set of modules, most of which should not be relevant, just tedious to eliminate. The important sources are datafield.f90, bottomwind.f90 and perturb.f90 ... well just start from dat_init_wind(), which exhibits the bug when called just after dat_init_density() (with inside call to pert_perturb()).
[Bug fortran/53778] bad code (delivering NaN instead of proper result) with -foptimize-sibling-calls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53778 --- Comment #3 from Thomas Orgis 2012-06-27 09:03:25 UTC --- ... and not to forget profiles.f90 ... that module links the perturbation in dat_init_density() to the wind in dat_init_wind(). Changes in there along with moving perturb to using those same profiles as the wind triggered the bug to begin with. So, if it is something broken in my code, it is likely to be found in profiles.f90 or perturb.f90 ... or bottomwinds.f90 .
[Bug fortran/53778] bad code (delivering NaN instead of proper result) with -foptimize-sibling-calls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53778 --- Comment #4 from Dominique d'Humieres 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.6614401858304297NaN 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.
[Bug fortran/53778] bad code (delivering NaN instead of proper result) with -foptimize-sibling-calls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53778 --- Comment #5 from Tobias Burnus 2012-06-27 15:27:10 UTC --- (In reply to comment #4) > However if I add '-finit-real=snan -ffpe-trap=invalid,zero,overflow' to the\ > flags, the line [...] For me it fails with: #3 0x419D2B in __datafield_MOD_dat_init_wind at datafield.f90:211 #4 0x41B830 in show_state at test.f90:55 Floating point exception However, the problem is in profiles.f90's profile_values, called by: function profile_deriv(handle, y) result(deriv) ... call profile_values(handle, y, deriv=deriv) end function subroutine profile_values(handle, y, deriv, value, aderiv, aderiv2) ... if(zero(handle%length)) then val(0) = 1 return end if ... if(present(value)) value = val( 0) ... end subroutine Do you spot the uninitialized variable?
[Bug fortran/53778] bad code (delivering NaN instead of proper result) with -foptimize-sibling-calls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53778 Thomas Orgis changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #6 from Thomas Orgis 2012-06-27 21:31:06 UTC --- Meh ... I see it. Trapped by those optional fortran dummy arguments. All the fuss and hassle because of a dumb missing initialization. At least now I know why this specific configuration crashed (y dimension has length 0). OK, you're off the hook this time;-) I can kill compiler bug 25 from my list (not just gfortran) as invalid and so can you with this report. Thanks for investigating and also showing me the correct syntax to trap missing initializations (for some reason, I had -finit-real-nan in my flags before ... which is wrong in more than one way).
[Bug fortran/53778] bad code (delivering NaN instead of proper result) with -foptimize-sibling-calls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53778 --- Comment #7 from Thomas Orgis 2012-06-27 21:34:43 UTC --- Eh, it must have been -finit-real=nan ... so only wrong in one way;-)
