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