This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Meaning of TREE_ADDRESSABLE types (Was: [PATCH] Fix PR40389)
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