On 4/28/20 7:54 AM, Jakub Jelinek wrote:
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.
That sounds good.
Jason
