On Mon, 7 Apr 2014, Richard Biener wrote:
One hard part is avoiding duplicate warnings. Replacing the address with 0
is a convenient way to do that, so I did it both for my new warning and for
the existing C/C++ ones. The patch breaks
gfortran.dg/warn_target_lifetime_2.f90 because it ends up warning twice. I
didn't touch that front-end because I don't know fortran, and the warning
message "Pointer at .1. in pointer assignment might outlive the pointer
target" doesn't seem very confident that the thing really is broken enough
to be replaced by 0. I only tested (bootstrap+regression) the default
languages, so ada/go may have a similar issue, to be handled if the approach
seems ok. (I personally wouldn't care about duplicate warnings, but I know
some people can't help complaining about it)
This doesn't actually fix PR 60517, for that I was thinking of checking for
memory reads if the first stop of walk_aliased_vdefs is a clobber (could
also check __builtin_free), though I don't know in which pass to do that
yet.
Note that this will break "working" programs where inlining causes
those references to no longer be "returned" (though maybe they
already break with the clobbers we insert). I remember that POOMA/PETE
was full of this ... (and made it reliably work by flattening all call trees
with such calls).
I mostly see programs that are written and tested using "debug mode" and
that appear to be working, but break as soon as they are compiled in
"release mode" because of dangling references. Breaking them more seems
like a helpful thing to me ;-) (especially with a warning).
But I would be happy not replacing the pointer and only emitting a
warning, if people don't mind duplicate warnings or if we can find another
way to avoid them.
+ if (warning_at (gimple_location (stmt), OPT_Wreturn_local_addr,
+ "function returns address of local variable"))
That's a front-end option, I should either move it to gcc/common.opt or
use a different option.
--
Marc Glisse
