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). Thanks, Richard.