[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>]

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;-)