[Bug fortran/53778] New: bad code (delivering NaN instead of proper result) with -foptimize-sibling-calls
thomas.orgis at awi dot de
gcc-bugzilla@gcc.gnu.org
Tue Jun 26 09:37:00 GMT 2012
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53778
Bug #: 53778
Summary: bad code (delivering NaN instead of proper result)
with -foptimize-sibling-calls
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: fortran
AssignedTo: unassigned@gcc.gnu.org
ReportedBy: thomas.orgis@awi.de
Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
Build: x86_64-pc-linux-gnu
I have a function in my Fortran code base that looks like this:
function dat_init_wind(handle, x, perturb) result(wind)
type(datafield_t), intent(in) :: handle
real(kind=8), dimension(:), intent(in) :: x
logical, intent(in), optional :: perturb
real(kind=8), dimension(handle%world%dims) :: wind
logical :: pert
pert = .true.
if(present(perturb)) pert = perturb;
select case(handle%initial_state)
case(dat_init_geosiso)
wind = geosiso_wind(handle, handle%bottomwind, x)
case(dat_init_baroiso)
wind = baroiso_wind(handle, handle%bottomwind, x)
case(dat_init_baroclinpoly)
wind = baroclinpoly_wind(handle, handle%baroclinpoly, x)
case default
wind = handle%base_speeds * bottomwind_profile(handle%bottomwind,
world_map_y(handle%world, x))
end select_
if(pert .and. handle%perturb_wind /= 0) call pert_perturb(handle%pert,
wind(handle%perturb_wind), x, handle%world%scale%space /&
& handle%world%scale%time)
end function
This worked fine until a recent change, where I changed innerworkings of
pert_perturb(). Suddenly the result (wind) was a set of NaN instead of 0 (in
the considered configuration).
Note that pert is false, as is (handle%perturb_wind /= 0), so the changes to
pert_perturb() should have no influence on the result. Also, I noticed that
adding a printout to the function fixes things, even if it is not actually
called:
select case(handle%initial_state)
case(-100)
write(0,0) 'This is a stub that never is executed but prevent compiler
BUG 25 from triggering. Apparently.'
case(dat_init_geosiso)
Also, dropping the call to bottomwind_profile() from the 'default' case, which
is what is actually executed, fixes the issue, but makes the code rather no-op
for me. While the recent changes in my code also touch that function, it itself
still computes correclty (as does pert_perturb()).
That somehow fits with me narrowing down the issue to the minimal optimization
flags needed (down from simple -g -O2):
-O -g -foptimize-sibling-calls
(The -g can be dropped, I strongly assume.) So it is something with optimizing
function calls / stack mess-around.
Note that I was unable to further reduce what is behind -O, I can activate all
flags that make up -O here individually and the issue does not come into play.
But also, setting -O and disabling all flags also does not trigger (it's a
combination I guess). So it is <some unknown basic setting> plus sibling call
optimization.
Now, does this description ring a bell? It would be so swell if this situation
was clear enough to diagnose the error in gfortran's optimization. If not, I
will have to try to extract something self-contained out of my codebase again
... which might need considerable time.
If this issue is already known and something along that fixed (in 4.7,
perhaps?), that would be a nice surprise.
I apologize if this turns out to be a bug in my code after all, but since I
work with -fbounds-check -ffpe-trap=invalid,zero,overflow usually, I don't see
much possibility to produce such breakage in Fortran. If this were a C program,
I'd look harder for me messing up someplace;-)
More information about the Gcc-bugs
mailing list