On Tue, Apr 28, 2020 at 12:01:15PM -0500, Segher Boessenkool wrote:
> So the attribute says an object of this struct can have the same address
> as another object of this struct. But that is not what the backend code
> uses it for!
There is a FAQ at the start of the paper that says various intentions of
that and one of them seems to be that it would be interoperable with
the empty bases, dunno if e.g. using empty bases in C++17 and then in C++20
code use these instead, I think Jonathan could say more.
> > > It seems to me that we would be *much* better off saying what we want it
> > > to *do*, if we are going to depend on that effect anyway!
>
> ^^^ I have said it before as well, but it is just getting worse. This
> kind of frontend code has no business in a backend (all *other* backends
> might need something similar (or different!), too!)
While the C++17 empty base artificial field might look like that case,
as it is an artificially added field needed for the FE, though for the
-Wpsabi diagnostics we still need the backends now to see it and decide if
there is an ABI change or not, for these [[no_unique_address]] fields, they
are normal user fields, so I don't see how they could be hidden from the
middle-end, they need to go into debug info, one can take their address,
etc.
By having this single DECL_FIELD_ABI_IGNORED macro, we can mark all the
FIELD_DECLs that the backends should ignore, if further cases are ever
needed, and hopefully for those we won't need any -Wpsabi warnings because
we should get the ABI right immediately. Similarly to how the backends
ignore FUNCTION_DECLs, TYPE_DECLs and whatever else the FEs stick into
TYPE_FIELDS.
Jakub
