Jakub Jelinek <ja...@redhat.com> writes: > On Wed, Apr 22, 2020 at 12:17:02PM +0100, Richard Sandiford wrote: >> But my point was that, if the DECL_NAME does actually act to exclude > > I'm fine with dropping DECL_NAME test there, on the other side would like to > add > && TYPE_SIZE (TREE_TYPE (field)) > && !integer_zerop (TYPE_SIZE (TREE_TYPE (field))) > in there because that is what all these empty bases should satisfy too.
Sounds good to me FWIW. > If the predicate says that it is the C++17 empty base field, then it better > should be a narrow check. > Now, in the backend, one has the -Wpsabi diagnostics that also talks about > C++17, so I think it is better to use that predicate in there. Ack. > But, what one could do is verify that all other > if (DECL_SIZE (field) && integer_zerop (DECL_SIZE (field))) > fields don't matter for the ABI decisions. > So > if (TREE_CODE (field) != FIELD_DECL) > continue; > > if (cxx17_empty_base_field_p (field)) > { > /* hint -Wpsabi warning here somehow. */ > continue; > } > > sub_count = aapcs_vfp_sub_candidate (TREE_TYPE (field), modep); > > /* Verify that other zero sized fields don't affect the > ABI decisions. */ > if (DECL_SIZE (field) && integer_zerop (DECL_SIZE (field))) > gcc_assert (sub_count == 0); > > if (sub_count < 0) > return -1; > count += sub_count; > ? I fear this will actually trip in practice, but I'd have to go back and check. (This came up in the context of the SVE parameter-passing rules, where we ended up deliberately checking DECL_SIZE to avoid zero-size user-level decls.) E.g. I'd expect a :0 bitfield to have a zero size and an integer TREE_TYPE, so the recursive call should return -1. AIUI we should skip these kinds of bitfield too, but again that's just my understanding, not a definitive statement. Either way, I think we should deal with the other zero-size cases separately after GCC 10. Thanks, Richard