https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94383
--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
--- gcc/config/aarch64/aarch64.c.jj 2020-03-18 12:51:41.051640609 +0100
+++ gcc/config/aarch64/aarch64.c 2020-03-30 16:28:29.133717645 +0200
@@ -16030,6 +16030,16 @@ aapcs_vfp_sub_candidate (const_tree type
if (TREE_CODE (field) != FIELD_DECL)
continue;
+ /* Ignore C++17 empty base fields, while their type indicates
+ they do contain padding, they have zero size and thus don't
+ contain any padding. */
+ if (DECL_ARTIFICIAL (field)
+ && DECL_NAME (field) == NULL_TREE
+ && RECORD_OR_UNION_TYPE_P (TREE_TYPE (field))
+ && DECL_SIZE (field)
+ && integer_zerop (DECL_SIZE (field)))
+ continue;
+
sub_count = aapcs_vfp_sub_candidate (TREE_TYPE (field), modep);
if (sub_count < 0)
return -1;
fixes that. Though, guess there might need to be a -Wpsabi warning and that
would likely need propagate to callers whether such field has been seen and if
it has been seen, let the code retry in a mode where it wouldn't ignore those,
compare the result and if it is different, warn.
Will defer to aarch64 maintainers.
And, guess it would be nice to test other targets for similar issues.
Do we want e.g. to adjust struct-layout-1_generate.c, so that it only tests
structures with such an empty base and just check value passing of such classes
(both caller and callee at various spots in argument list) or returning,
compile everything in C++14 and C++17 and compare assembly, verify that it
fails on aarch64 and then look for others?
