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? Jakub
