[Bug fortran/53778] New: bad code (delivering NaN instead of proper result) with -foptimize-sibling-calls

[Bug fortran/53778] New: bad code (delivering NaN instead of proper result) with -foptimize-sibling-calls

[thomas.orgis at awi dot de]

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

[Bug fortran/53778] bad code (delivering NaN instead of proper result) with -foptimize-sibling-calls

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53778

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu.org

--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> 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

[thomas.orgis at awi dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53778

--- Comment #2 from Thomas Orgis <thomas.orgis at awi dot de> 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

[thomas.orgis at awi dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53778

--- Comment #3 from Thomas Orgis <thomas.orgis at awi dot de> 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

[dominiq at lps dot ens.fr]

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.

[Bug fortran/53778] bad code (delivering NaN instead of proper result) with -foptimize-sibling-calls

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53778

--- Comment #5 from Tobias Burnus <burnus at gcc dot gnu.org> 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

[thomas.orgis at awi dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53778

Thomas Orgis <thomas.orgis at awi dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID

--- Comment #6 from Thomas Orgis <thomas.orgis at awi dot de> 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

[thomas.orgis at awi dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53778

--- Comment #7 from Thomas Orgis <thomas.orgis at awi dot de> 2012-06-27 21:34:43 UTC ---
Eh, it must have been -finit-real=nan ... so only wrong in one way;-)