This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: GCC 3.2
- From: Jason Merrill <jason at redhat dot com>
- To: Mark Mitchell <mark at codesourcery dot com>
- Cc: Franz Sirl <Franz dot Sirl-kernel at lauterbach dot com>,"gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>,"Kevin B. Hendricks" <kevin dot hendricks at sympatico dot ca>,Jakub Jelinek <jakub at redhat dot com>,"gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 01 Aug 2002 22:42:23 +0100
- Subject: Re: GCC 3.2
- References: <40360000.1027723811@gandalf.codesourcery.com><200207271635.12319@enzo.bigblue.local><wvlptx6m7pd.fsf@prospero.cambridge.redhat.com><wvly9bsk9gg.fsf@prospero.cambridge.redhat.com><3000000.1028131037@gandalf.codesourcery.com>
On Wed, 31 Jul 2002 08:57:17 -0700, Mark Mitchell <mark@codesourcery.com> wrote:
>> With this patch, the empty class passing hackery can go away, hurrah.
>
> Yay.
>
>> BTW, why do we use stubs for langhook defaults? I would think leaving the
>> hook entry NULL would be more efficient for languages that are happy with
>> the default, as a comparison to zero is much cheaper than an indirect
>> jump...
>
> Well, what I would do is simply move the current expr_size_unit into the
> new hook. Then, have the C++ hook call the generic hook if it doesn't
> want to override it.
Could do that, I suppose.
> + tree
> + cp_expr_size (exp)
> + tree exp;
> + {
> + if (CLASS_TYPE_P (TREE_TYPE (exp)))
> + return CLASSTYPE_SIZE_UNIT (TREE_TYPE (exp));
> + else
> + /* Use the default code. */
> + return NULL_TREE;
> + }
>
> Isn't that the size without virtual base classes? What if the expression
> is for a complete object with virtual bases?
>
> A good answer is that in that case the C++ front end will never present
> the back end with an expression like that requiring copying. In that
> case, there should be an assert and a comment indicating that in
> cp_expr_size so that we can tell if we screw up.
Good thought. Indeed, adding such an assert exposes a long-standing bug
with g++.bugs/900331_03.C where a SAVE_EXPR was causing us to bitwise copy
a class for which that is inappropriate. Will fix.
> Overall, I think I'd rather we wait for 3.2.1 for this patch -- but then
> I think it's a good idea.
That's what I was thinking. I'm also thinking to reserve the empty class
bits for the trunk, to be safe.
Jason