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: Alan Modra <amodra at gmail dot com>
- To: Marc Glisse <marc dot glisse at inria dot fr>
- Cc: Jeff Law <law at redhat dot com>, gcc-patches at gcc dot gnu dot org
- Date: Wed, 2 Jul 2014 21:49:04 +0930
- 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> <alpine dot DEB dot 2 dot 10 dot 1406291111050 dot 2096 at laptop-mg dot saclay dot inria dot fr> <53B1D0C5 dot 30901 at redhat dot com> <alpine dot DEB dot 2 dot 10 dot 1406302319090 dot 2048 at laptop-mg dot saclay dot inria dot fr>
On Mon, Jun 30, 2014 at 11:37:50PM +0200, Marc Glisse wrote:
> 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.
At least on powerpc64, which uses a caller allocated parameter save
area, returning the address of something in the parameter save area
merits a warning. The ABIs explicitly state that the parameter save
area is not preserved over function calls.
Also note that anything left in a caller allocated parameter save area
will potentially be trashed by arguments written for the next call.
Australia Development Lab, IBM