https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88450
--- Comment #16 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The following patch does that. Guess the issues reported in this PR might go
away with that, but it is really just an attempt to fix inefficiency in the
generated code rather than fix the wrong-code issue we have somewhere.
--- gcc/config/i386/i386.c.jj 2019-01-08 22:33:34.605708026 +0100
+++ gcc/config/i386/i386.c 2019-01-09 15:11:35.902663636 +0100
@@ -29679,6 +29679,17 @@ ix86_local_alignment (tree exp, machine_
&& (!type || !TYPE_USER_ALIGN (type))
&& (!decl || !DECL_USER_ALIGN (decl)))
align = 32;
+ /* Similarly, don't do dynamic stack realignment just because
+ we need a BLKmode stack slot and have high BIGGEST_ALIGNMENT.
+ This is what get_stack_local_alignment returns regardless of
+ the actual needs, undo that here. */
+ if (align == BIGGEST_ALIGNMENT
+ && mode == BLKmode
+ && !decl
+ && type
+ && align > TYPE_ALIGN (type)
+ && align > MAX_SUPPORTED_STACK_ALIGNMENT)
+ align = MAX (TYPE_ALIGN (type), MAX_SUPPORTED_STACK_ALIGNMENT);
/* If TYPE is NULL, we are allocating a stack slot for caller-save
register in MODE. We will return the largest alignment of XF
--- gcc/function.c.jj 2019-01-09 11:15:31.539836837 +0100
+++ gcc/function.c 2019-01-09 15:10:52.971371328 +0100
@@ -919,8 +919,10 @@ assign_stack_temp_for_type (machine_mode
So for requests which depended on the rounding of SIZE, we go ahead
and round it now. We also make sure ALIGNMENT is at least
- BIGGEST_ALIGNMENT. */
- gcc_assert (mode != BLKmode || align == BIGGEST_ALIGNMENT);
+ minimum of BIGGEST_ALIGNMENT and MAX_SUPPORTED_STACK_ALIGNMENT. */
+ gcc_assert (mode != BLKmode
+ || align >= MIN (BIGGEST_ALIGNMENT,
+ MAX_SUPPORTED_STACK_ALIGNMENT));
p->slot = assign_stack_local_1 (mode,
(mode == BLKmode
? aligned_upper_bound (size,
