Re: [C++ PATCH] Don't create an INTEGER_CST for aggregates (empty structs)

[Andrew Pinski <pinskia at physics dot uc dot edu>]

On Mar 10, 2005, at 1:15 PM, Paolo Carlini wrote:

> Hi Andrew,
>
> and, first, thanks for the help.
>
> > The C++ front-end creates an INTEGER_CST with a record type which 
> > seems wrong and
> > could cause bugs in the future.  This patch fixes it by creating an 
> > empty
> > constructor instead which is the correct thing to do.  I found this 
> > while looking
> > into how to fix PR 20408 and I had originally thought this was the 
> > cause of that
> > PR.  Anyways we create these for empty structs only when we are 
> > gimplifing
> > EMPTY_CLASS_EXPR.
>
> I wonder (very naively, sorry) why this construction work?!? I mean, 
> if the memory allocated for an EMPTY_CLASS_EXPR is considered simply 
> as a data member of built-in type, automatically no actual 
> construction is needed. I must be missing something (ABI-related?) 
> otherwise I cannot understand why we cannot deal with an 
> EMPTY_CLASS_EXPR similarly to
>
>    struct EMPTY_CLASS_TYPE
>    {
>       char dummy;
>    };
>
>    EMPTY_CLASS_TYPE EMPTY_CLASS_EXPR;

A CONSTRUCTOR in the middle-end means "{xxx,yyy}" and not calling the 
constructor
of the class.

Even if we don't have a CONSTRUCTOR here, removing the code which 
produces the
EMPTY_CLASS_EXPR and changing the testcase to:
struct a{};
void f(a);
void g(){a b; f(b);}
We still get the same code as before, though we do get better code for 
the following:
struct a{};
void f(a);
void g(a b) { f(b); }

Since the classes in C++ always have a size greater than zero, we have 
to pass them
instead of not passing them (well if we don't it would cause an ABI 
change).

I wonder how much of this code comes from when the size of the empty 
struct
in the C++ front-end was zero.

-- Pinski