Re: Warn when returning the address of a temporary (middle-end) v2

[Marc Glisse <marc dot glisse at inria dot fr>]

On Mon, 30 Jun 2014, Jeff Law wrote:

> On 06/29/14 03:22, Marc Glisse wrote:
> > After looking at PR 61597, I updated the 2 conditions to:
> >
> > +          if ((TREE_CODE (valbase) == VAR_DECL
> > +               && !is_global_var (valbase))
> > +              || TREE_CODE (valbase) == PARM_DECL)
> >
> > a PARM_DECL is a local variable and returning its address is wrong,
> > isn't it?
> Right.  It can live in either a caller or callee allocated slot.

The "caller" case scares me a bit. Is it really wrong to return the 
address in that case? The slot still exists after returning if the caller 
is responsible for it.

> When I first glanced at the patch my thought was "why is this in the path 
> isolation pass?"

A very pragmatic reason is that you and Richard asked me to after v1 of 
the patch... It doesn't matter that much to me where this goes.

> But I see you want to modify the returned value to be NULL. 
> I'll have to look at why you want to do that, but at least I understand why 
> it's utilizing the path isolation code.

Originally I mostly wanted to avoid warning several times. Now that the 
warning is in a pass that runs only once, it isn't that necessary (it 
remains necessary to do something in the front-end to avoid warning again 
in the middle-end). It is still an optimization (it probably helps remove 
dead code), though I could replace 0 with an undefined variable.

--
Marc Glisse