Meaning of TREE_ADDRESSABLE types (Was: [PATCH] Fix PR40389)

Jakub Jelinek jakub@redhat.com
Tue Jun 16 09:40:00 GMT 2009


On Tue, Jun 16, 2009 at 11:21:18AM +0200, Richard Guenther wrote:
> On Tue, 16 Jun 2009, Martin Jambor wrote:
> 
> > On Mon, Jun 15, 2009 at 04:12:16PM +0200, Richard Guenther wrote:
> > > This is a variant for the 4.4 branch.  If we can settle on
> > > testing TREE_ADDRESSABLE on the object, not the type (or if somebody
> > > can explain me what TREE_ADDRESSABLE on types semantically means
> > > for the middle-end and how this relates to the failure mode).
> > > 
> > 
> > I have pondered  over this too.  As far as  I understand it correctly,
> > the flag is  overloaded, has nothing to do  with addressability of the
> > instances of the  type and the comment in  tree.h is wrong.  Certainly
> > SRA has to  be able to split  them or we get very  poor performance in
> > C++.
> > 
> > Instead, what it (again, IIUC) means  is that the instances have to be
> > somehow specially constructed when created.  In middle end that has at
> > least one important consequence,  we cannot create temporary variables
> > of these  types (either directly or  through force_gimple_operand, for
> > example).
> 
> Ok, this sort-of was my understanding as well.  But I do not see
> how this is connected to the NRV issue at all - certainly if NRV
> is applied the caller can take the address of the return slot if
> the language standard says that is a valid thing to do.  Now the
> question is if that is only valid for 1) C++, 2) these kind of
> special types.
> 
> ?

Taking address of a temporary and remembering it from callee to caller when
passed by invisible reference, if it doesn't have TREE_ADDRESSABLE type, is
quite fuzzy, at least I don't see how a valid program could do it.
The problem is that if the temporary doesn't have a non-trivial destructor
(I believe non-trivial destructor implies TREE_ADDRESSABLE type), the code
has no way to know when the temporary goes out of scope in the caller and
thus can't stop remembering its address at that point.

	Jakub



More information about the Gcc-patches mailing list