https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103147
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org,
| |jonathan.wright at arm dot com,
| |wirkus at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Note, -fpack-struct is an ABI changing option, so it should be used with extra
care.
Anyway, I guess the backends (both aarch64 and arm) need to decide what exactly
they want.
Either for these internal lang_hooks.types.simulate_record_decl created types
temporarily rest to default the -fpack-struct stuff, or allow them to have
smaller alignment, or increase the alignment afterwards.
Because those
tree t = lang_hooks.types.simulate_record_decl (input_location,
tuple_type_name,
make_array_slice (&field,
1));
gcc_assert (TYPE_MODE_RAW (t) == TYPE_MODE (t)
&& TYPE_ALIGN (t) == alignment);
and
ls64_arm_data_t = lang_hooks.types.simulate_record_decl (input_location,
tuple_type_name,
make_array_slice (&field, 1));
gcc_assert (TYPE_MODE (ls64_arm_data_t) == V8DImode);
gcc_assert (TYPE_MODE_RAW (ls64_arm_data_t) == TYPE_MODE (ls64_arm_data_t));
gcc_assert (TYPE_ALIGN (ls64_arm_data_t) == 64);
assertions otherwise of course fail.
Now, seems the arm backend actually doesn't assert this.
Note, when those types were defined in arm_neon.h, -fpack-struct usedd to be
applied to those.
The changes were done in r12-4907-g8197ab94b47c814632d758dd36a121ad4114ff70
and r12-5955-gfdcddba8f29ea3878851b8b4cd37d0fd3476d3bf
