On Tue, Apr 28, 2020 at 07:44:26AM -0400, Jason Merrill via Gcc-patches wrote:
> > Or do we have to further check that it
> > really doesn't contain any fields other than empty classes?
> > E.g. some of the ABIs pass differently:
> > struct A {};
> > struct B { A a; float b, c, d; };
> > struct C { int : 0; };
> > struct D { C a; float b, c, d; };
> > because the zero sized bitfield is spelled in the ABI as causing different
> > behavior.
> > Other ABIs look for first field and do something if it is of some kind (or
> > if it is the first and only say float or vector field).
> > E.g. the powerpc-darwin or powerpc*-aix* ABIs do different alignment
> > depending on if it is:
> > struct E {};
> > struct F { double d; };
> > or
> > struct G { E e; double d; };
> >
> > One can just grep the backends for TYPE_FIELDS walks...
>
> Is there a bitfield in FIELD_DECL we could use to mean 'this field should
> not affect ABI' (other than as the front end has already used it for
> layout)? From tree-core.h it looks like addressable_flag, static_flag,
> public_flag, asm_written_flag, nothrow_flag, saturating_flag,
> default_def_flag are all unused on FIELD_DECL.
Because of the -Wpsabi diagnostics that (some) targets want, having
just one bit "ignore this FIELD_DECL in ABI decisions" is not good enough.
If we want to use some bit, perhaps
(FIELD_DECL_CHECK (NODE)->decl_common.decl_flag_0)
could be used to mark something, either the C++17 empty bases only,
or both those and [[no_unique_address]] and then the backends could use
lookup_attribute ("no_unique_address", DECL_ATTRIBUTES (field))
to find out if it is the C++14 vs. C++17 ABI incompatibility, or the
all C++ versions [[no_unique_address]] thing.
See the powerpc64le-linux patch I've just posted.
Jakub
