This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]