This is the mail archive of the gcc-patches@gcc.gnu.org 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]

Re: [C++ PATCH]: Fix empty class copying


Jason Merrill wrote:
> > * Any polymorphic class sets COMPLEX_ASSIGN_REF (previously it was
> > only those with virtual bases).
> 
> That should use TYPE_CONTAINS_VPTR_P.  We still care about the case of a
> class with vbases and no virtual functions.
Doh! brain fart.


> > * build_over_call only tries to optimize the copy ctor of an empty
> > class iff it does not need constructing
> 
> Why?  I don't follow the comment in the code.
Previously, when ARG was !real_lvalue_p, we'd emit
	build (INIT_EXPR, DECL_CONTEXT (fn), to, arg);
for non-empty objects, and
	build (MODIFY_EXPR, DECL_CONTEXT (fn), to, arg);
for empty ones. The comment before that explains
a) why we need a modify expr, so that TYPE_NONCOPIED_PARTS comes into play
b) we can't just ignore ARG, as it might have a TARGET_EXPR and we'd have
unbalanced ctor/dtor pairing.

The bug was (a) is flawed when the class is empty, but has an empty base
class. TYPE_NON_COPIED_PARTS is inactive and we end up smashing whatever
overlaid the empty object in the class it belongs to. So we can't use
the MODIFY_EXPR trick. We have to either a) do the copy ctor the hard way
or default construct TO and leave ARG to be dtor'd later. (I could not
think of another way of acheiving the desired outcome.) So the type
must have a default ctor.

Now, an empty class may or may not have trivial ctor, copyctor & dtor.
It might *not* have a default ctor. If it does have a default ctor, I
think it only safe if that is trivial. The std allows us to elide copies,
but I don't think it allows us to turn (pseudocode)
	ARG.ctor (whatever);
	TO.ctor (ARG);	<- we are here
	ARG.dtor ();
	TO.dtor ()
into
	ARG.ctor (whatever);
	TO.ctor ();
	ARG.dtor ();
	TO.dtor ();
except by the 'as-if' rule. If the default constructor is non-trivial
we can't invoke the 'as-if' rule. Because, of course, some user
might have the highly user visible statement
	launch_nuclear_weapons_now ();
inside the default ctor of the empty class.

Do you agree? (I'll try and reword the comment)

While writing this, I think there's another user visible effect. The
original, unoptimized code sequence consisted of some ctor into ARG,
a copy ctor, and two dtors. We're allowed to turn that into some ctor
into TO and a single dtor. My patch turns it into some ctor into ARG,
an (invisible) default ctor of TO, and *two* dtors (which may or may
not be user visible). Perhaps I'm over analysing this, but maybe
we can only do the above when there is a trivial dtor too.

> Would we?  I've had the same thought, but I'm not sure it's true.  The
> cases where we can eliminate copies are fairly few; apart from the named
> return value optimization, we've handled them fine for a while now.
Maybe you're right, but what about when inlining? Can we not eliminate
parameters?

nathan

-- 
Dr Nathan Sidwell   ::   http://www.codesourcery.com   ::   CodeSourcery LLC
         'But that's a lie.' - 'Yes it is. What's your point?'
nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org


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