https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88450
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |uros at gcc dot gnu.org
--- Comment #15 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Because you are using -march=native -mtune=native by default, it is unclear
what exact ISA/tuning that is. From the dump I assume it must be something
with -mavx or -mavx2, so that is what I've used, but it would be nice to know
it more exact. Guess ./xgcc -B ./ -v -xc /dev/null -S would reveal that.
Anyway, seems on gimplify.ii the problematic change in assign_stack_local_1 is
triggered just once, and to me it looks completely unnecessarily.
assign_stack_temp_for_type is called with BLKmode, 24, and gimple_stmt_iterator
type. This is done because on the
seq = gsi_split_seq_after (iter);
call in gimplify_cleanup_point_expr inlined into gimplify_expr where iter is
clearly passed by invisible reference.
assign_stack_temp_for_type calls get_stack_local_alignment which does:
if (mode == BLKmode)
alignment = BIGGEST_ALIGNMENT;
else
alignment = GET_MODE_ALIGNMENT (mode);
/* Allow the frond-end to (possibly) increase the alignment of this
stack slot. */
if (! type)
type = lang_hooks.types.type_for_mode (mode, 0);
return STACK_SLOT_ALIGNMENT (type, mode, alignment);
It seems complete waste to me try to align the 24 byte structure to 32 byte
boundary and allocate 48 bytes for it on the stack, then dynamically adjust the
start so that it is 32 byte aligned. BIGGEST_ALIGNMENT is 256 bits because of
-mavx (could be even 512 bits for -mavx512f).
So, first of all, I'd think we should in i386 STACK_SLOT_ALIGNMENT undo this
unnecessary overalignment. But that doesn't explain why you get segfault
elsewhere.
