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
