[Bug fortran/52176] New: Valgrind complains about some realloc on assignment to unallocated LHS

[Bug fortran/52176] New: Valgrind complains about some realloc on assignment to unallocated LHS

[dominiq at lps dot ens.fr]

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

             Bug #: 52176
           Summary: Valgrind complains about some realloc on assignment to
                    unallocated LHS
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: dominiq@lps.ens.fr
                CC: burnus@gcc.gnu.org, pault@gcc.gnu.org


At revision 184016, the executable for Rouson et al code in
chapter08/puppeteer_f2003 passes valgrind without error up to -O. For higher
optimization, valgrind complains:

==6241== Conditional jump or move depends on uninitialised value(s)
==6241==    at 0x100004E46: MAIN__.2374 (main.F90:95)
==6241==    by 0x10000755E: main (main.F90:27)

this is

      jacobian = identity - 0.5*dt*dRHS_dState

and a lot of

==6153== Conditional jump or move depends on uninitialised value(s)
==6153==    at 0x100005258: __air_module_MOD_coordinate (air.F90:82)
==6153==    by 0x1000070BF: ??? (in ./a.out)
==6153==    by 0x10000728F: ??? (in ./a.out)
==6153==    by 0x1000070BF: ??? (in ./a.out)
==6153==    by 0x100454B8F: ???
==6153==    by 0x1000070BF: ??? (in ./a.out)
==6153==    by 0x208: ???

this is

  ! accessor: returns phase-space coordinates
  function coordinate(this) result(return_x)
    class(air)          ,intent(in)  :: this
    real  ,dimension(:) ,allocatable :: return_x
    return_x = [ this%x ,this%sigma ]
  end function

Adding

    allocate(return_x(2))

fixes the later errors. Note that running the executable outside valgrind seems
to give the right results even with -Ofast -flto.

[Bug fortran/52176] Valgrind complains about some realloc on assignment to unallocated LHS

[burnus at gcc dot gnu.org]

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

--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-02-09 17:02:36 UTC ---
gfortran generates the following code (original dump). I think, it's 

        if ((real(kind=4)[0:] * restrict) __result->data == 0B) goto L.17;
        L.17:;
        D.2061 = __result->dim[0].ubound - __result->dim[0].lbound >= 0
           ? (__result->dim[0].ubound - __result->dim[0].lbound) + 1 : 0;
        D.2062 = D.2061 != 2;
        if ((real(kind=4)[0:] * restrict) __result->data == 0B)
          ...
        else
            if (D.2062)

where those equations are not used in an "if", if result->data == NULL.
However, in the optimized dump, one finds:

  [air.F90 : 82:0] prephitmp.78_7 = [air.F90 : 82] __result_6(D)->data;
  [air.F90 : 82:0] if (prephitmp.78_7 == 0B)
    goto <bb 3>;
<bb 3>:
  prephitmp.77_85 = __result_6(D)->dim[0].ubound;
  [air.F90 : 82:0] D.2085_25 = prephitmp.77_79 - D.2057_9;
  [air.F90 : 82:0] if (D.2085_25 >= 0)
    ...
  [air.F90 : 82:0] if (prephitmp.78_7 == 0B)
    goto <bb 8>;
  else
    goto <bb 9>;

Thus, the bounds are always accessed in the "if", even if the result->data ==
NULL. However, in terms of the result, it does not seem to matter as far as I
could see.


However, I think the issue above is not related to the warning I see. valgrind
can only track uninitialized variables which have been allocated ("malloc") but
in this case "result" is a local variable, which should be stack allocated.
>From the callee (state_vector, atmosphere.F90:187):
    real ,dimension(:) ,allocatable :: x
    x = this%air_puppet%coordinate()

I think one should see such a valgrind error for allocatable components of
allocatable/pointer derived types as then also "<var>.dim" is malloc'ed.

If my analysis is correct, I do not see why valgrind warns. Nor do I understand
the reordering of the middle end. But at least the case above looks as if it's
not a wrong-code issue.

[Bug fortran/52176] Valgrind complains about some realloc on assignment to unallocated LHS

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2013-06-29
     Ever confirmed|0                           |1

--- Comment #2 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
What should I do with this PR?

[Bug fortran/52176] Valgrind complains about some realloc on assignment to unallocated LHS

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
With valgrind 3.7.0 and gfortran 4.9.0 r208594, I no longer see the

Conditional jump or move depends on uninitialized value

if I don't use -flto, while I still see them with 4.8.2. Note the errors are
back for 4.9 if I compile with -flto.

I all cases I see some "... blocks are still reachable in loss record ..."
messages related to I/Os (in write_float).

[Bug fortran/52176] Valgrind complains about some realloc on assignment to unallocated LHS

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52176

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|---                         |FIXED

--- Comment #4 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
I no longer see the valgrind problem from 4.9.3 up to trunk (6.0). the test
also runs without error if compiled with -fsanitize=address. Closing as FIXED.