[PATCH] c++, abi: Set DECL_FIELD_ABI_IGNORED on C++ zero width bitfields [PR102024]

Richard Biener rguenther@suse.de
Tue Aug 31 09:15:52 GMT 2021

On Tue, 31 Aug 2021, Jakub Jelinek wrote:

> On Tue, Aug 31, 2021 at 09:57:44AM +0200, Richard Biener wrote:
> > Just to clarify - in the C++ FE these fields are meaningful for
> > layout purposes but they are only supposed to influence layout
> > but not ABI (but why does the C++ FE say that?) and thus the
> > 'DECL_FIELD_ABI_IGNORED' is a good term to use?  But we still want
> > to have the backends decide whether to actually follow this advice
> > and we do expect some to not do this?
> The removal of zero-width bitfields was added (after structure layout)
> by
> https://gcc.gnu.org/legacy-ml/gcc-patches/1999-12/msg00589.html
> https://gcc.gnu.org/legacy-ml/gcc-patches/1999-12/msg00641.html
> The comment about it was:
> /* Delete all zero-width bit-fields from the list of fields.  Now
>    that we have layed out the type they are no longer important.  */
> The only spot I see zero-width bit-fields mentioned in the Itanium ABI is:
> empty class
>   A class with no non-static data members other than empty data members,
>   no unnamed bit-fields other than zero-width bit-fields, no virtual functions,
>   no virtual base classes, and no non-empty non-virtual proper base classes. 
> nearly empty class
>   A class that contains a virtual pointer, but no other data except (possibly) virtual bases. In particular, it:
>    - has no non-static data members and no non-zero-width unnamed bit-fields,
>    - has no direct base classes that are not either empty, nearly empty, or virtual,
>    - has at most one non-virtual, nearly empty direct base class, and
>    - has no proper base class that is empty, not morally virtual, and at an offset other than zero. 
>   Such classes may be primary base classes even if virtual, sharing a virtual pointer with the derived class. 
> and the removal of remove_zero_width_bit_fields I believe didn't change
> anything on that, e.g. is_empty_class uses CLASSTYPE_EMPTY_P flag whose
> computation takes:
>       if (DECL_C_BIT_FIELD (field)
>           && integer_zerop (DECL_BIT_FIELD_REPRESENTATIVE (field)))
>         /* We don't treat zero-width bitfields as making a class
>            non-empty.  */
>         ;
> into account (that is still before the bit-fields are finalized so
> width is stored differently, and it is necessary before the
> former remove_zero_width_bit_fields call).
> The flag for these zero-width bitfields is a good name for the case
> where a target decides to keep the old GCC 11 ABI of not ignoring them
> for C and ignoring them for C++, in other cases it can be a little bit
> confusing, but I think we could define another macro with the same
> value for it if we find a good name for it (dunno what it would be though).
> But even if we have another name, if we reuse the flag we need to take
> it into account in the target code, and using a different flag would be a
> waste of the precious bits.
> Perhaps just clarify in tree.h above the DECL_FIELD_ABI_IGNORED the cases
> in which it is set?

Yeah, I think it conflates the C++ [Itanium] ABI and the psABI for
calling conventions.  The 'ABI' in DECL_FIELD_ABI_IGNORED refers
to the psABI as far as I understand the situation, but then it
might still be important for the psABI when dealing with
(non-)homogenous aggregates ...

So _maybe_ DECL_FIELD_FOR_LAYOUT might capture the bits better - the
field is present for layout (and possibly ABI), but it doesn't carry
any data so it doesn't have to be passed across function boundary
for example.

Anyway, I'm not stuck to whatever naming we choose but the situation
is complicated enough that we want some more elaborate docs in tree.h
I'll leave the final ACK to Jason (unless he's on vacation).


More information about the Gcc-patches mailing list