public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/52176] New: Valgrind complains about some realloc on assignment to unallocated LHS
@ 2012-02-08 20:42 dominiq at lps dot ens.fr
2012-02-09 17:03 ` [Bug fortran/52176] " burnus at gcc dot gnu.org
` (3 more replies)
0 siblings, 4 replies; 5+ messages in thread
From: dominiq at lps dot ens.fr @ 2012-02-08 20:42 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug fortran/52176] Valgrind complains about some realloc on assignment to unallocated LHS
2012-02-08 20:42 [Bug fortran/52176] New: Valgrind complains about some realloc on assignment to unallocated LHS dominiq at lps dot ens.fr
@ 2012-02-09 17:03 ` burnus at gcc dot gnu.org
2013-06-29 15:46 ` dominiq at lps dot ens.fr
` (2 subsequent siblings)
3 siblings, 0 replies; 5+ messages in thread
From: burnus at gcc dot gnu.org @ 2012-02-09 17:03 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug fortran/52176] Valgrind complains about some realloc on assignment to unallocated LHS
2012-02-08 20:42 [Bug fortran/52176] New: Valgrind complains about some realloc on assignment to unallocated LHS dominiq at lps dot ens.fr
2012-02-09 17:03 ` [Bug fortran/52176] " burnus at gcc dot gnu.org
@ 2013-06-29 15:46 ` dominiq at lps dot ens.fr
2014-03-22 22:47 ` dominiq at lps dot ens.fr
2015-09-08 12:45 ` dominiq at lps dot ens.fr
3 siblings, 0 replies; 5+ messages in thread
From: dominiq at lps dot ens.fr @ 2013-06-29 15:46 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug fortran/52176] Valgrind complains about some realloc on assignment to unallocated LHS
2012-02-08 20:42 [Bug fortran/52176] New: Valgrind complains about some realloc on assignment to unallocated LHS dominiq at lps dot ens.fr
2012-02-09 17:03 ` [Bug fortran/52176] " burnus at gcc dot gnu.org
2013-06-29 15:46 ` dominiq at lps dot ens.fr
@ 2014-03-22 22:47 ` dominiq at lps dot ens.fr
2015-09-08 12:45 ` dominiq at lps dot ens.fr
3 siblings, 0 replies; 5+ messages in thread
From: dominiq at lps dot ens.fr @ 2014-03-22 22:47 UTC (permalink / raw)
To: gcc-bugs
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).
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug fortran/52176] Valgrind complains about some realloc on assignment to unallocated LHS
2012-02-08 20:42 [Bug fortran/52176] New: Valgrind complains about some realloc on assignment to unallocated LHS dominiq at lps dot ens.fr
` (2 preceding siblings ...)
2014-03-22 22:47 ` dominiq at lps dot ens.fr
@ 2015-09-08 12:45 ` dominiq at lps dot ens.fr
3 siblings, 0 replies; 5+ messages in thread
From: dominiq at lps dot ens.fr @ 2015-09-08 12:45 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2015-09-08 12:45 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-02-08 20:42 [Bug fortran/52176] New: Valgrind complains about some realloc on assignment to unallocated LHS dominiq at lps dot ens.fr
2012-02-09 17:03 ` [Bug fortran/52176] " burnus at gcc dot gnu.org
2013-06-29 15:46 ` dominiq at lps dot ens.fr
2014-03-22 22:47 ` dominiq at lps dot ens.fr
2015-09-08 12:45 ` dominiq at lps dot ens.fr
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).