This is the mail archive of the
mailing list for the GCC project.
Re: Warn when returning the address of a temporary (middle-end) v2
- From: Jeff Law <law at redhat dot com>
- To: Marc Glisse <marc dot glisse at inria dot fr>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Wed, 30 Jul 2014 22:53:30 -0600
- Subject: Re: Warn when returning the address of a temporary (middle-end) v2
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot DEB dot 2 dot 02 dot 1406221930380 dot 20514 at stedding dot saclay dot inria dot fr> <53C746CC dot 1000007 at redhat dot com> <alpine dot DEB dot 2 dot 11 dot 1407221056190 dot 1843 at laptop-mg dot saclay dot inria dot fr>
On 07/22/14 03:03, Marc Glisse wrote:
I must have missed that whole block of code. So, no, I don't think you
missed anything. My bad. I'm going to choose to blame it on using a
laptop screen on the road rather than my usual monitor at home.
I note you don't catch return &localvar in the isolation code -- it
looks like you just catch those which potentially flow from PHIs.
I thought I was handling it in the find_explicit_erroneous_behaviour
part of the patch (as opposed to the implicit part which deals with
PHIs). Function f1 in the testcase addrtmp.c has no PHI. Am I missing
Note my comment/question makes no sense now that we've settled that you
do have the right code in find_explicit_erroneous_behavior :-)
I realize you're primarily catching that in the front-ends, but can't
we have cases which aren't caught by the front end, but after
optimizations we're able to propagate &somelocal into the return
We can, and it was my original motivation. I only added PHI handling
when you asked for it.
It generally looks good and I'm ready to approve if the answer to the
above question is "can't happen". If it can happen, then we ought to
handle it in the isolation code as well (ought to be relatively easy).
Just to be clear, the approval would include the PARM_DECL tweak in