[C++ PATCH] Don't create an INTEGER_CST for aggregates (empty structs)
Andrew Pinski
pinskia@physics.uc.edu
Thu Mar 10 18:27:00 GMT 2005
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
More information about the Gcc-patches
mailing list