[Bug rtl-optimization/109276] New: ICE: in assign_stack_local_1, at function.cc:429 with -mpreferred-stack-boundary=2

[Bug rtl-optimization/109276] New: ICE: in assign_stack_local_1, at function.cc:429 with -mpreferred-stack-boundary=2

[max.aehle at scicomp dot uni-kl.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109276

            Bug ID: 109276
           Summary: ICE: in assign_stack_local_1, at function.cc:429 with
                    -mpreferred-stack-boundary=2
           Product: gcc
           Version: 12.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: rtl-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: max.aehle at scicomp dot uni-kl.de
  Target Milestone: ---

Created attachment 54745
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54745&action=edit
verbose output, preprocessed source, .i and .s file

Compiling the attached bug.c with GCC 12.2.0 via

    gcc -m32 -O0 -c bug.c -mpreferred-stack-boundary=2

prints

during RTL pass: split1
bug.c: In function 'fun':
bug.c:23:1: internal compiler error: in assign_stack_local_1, at
function.cc:429
   23 | }
      | ^
0x6d3b9b assign_stack_local_1(machine_mode, poly_int<1u, long>, int, int)
        /ramdisk/aehle/gcc/gcc-obj/../gcc-12.2.0/gcc/function.cc:429
0xf81d50 assign_386_stack_local(machine_mode, ix86_stack_slot)
        /ramdisk/aehle/gcc/gcc-obj/../gcc-12.2.0/gcc/config/i386/i386.cc:16558
0x13bdd87 gen_split_65(rtx_insn*, rtx_def**)
        /ramdisk/aehle/gcc/gcc-obj/../gcc-12.2.0/gcc/config/i386/i386.md:5471
0x17d3e0a split_insns(rtx_def*, rtx_insn*)
        /ramdisk/aehle/gcc/gcc-obj/../gcc-12.2.0/gcc/config/i386/i386.md:15646
0x9295fe try_split(rtx_def*, rtx_insn*, int)
        /ramdisk/aehle/gcc/gcc-obj/../gcc-12.2.0/gcc/emit-rtl.cc:3795
0xc01fb1 split_insn
        /ramdisk/aehle/gcc/gcc-obj/../gcc-12.2.0/gcc/recog.cc:3384
0xc072f2 split_all_insns()
        /ramdisk/aehle/gcc/gcc-obj/../gcc-12.2.0/gcc/recog.cc:3488
0xc073e8 execute
        /ramdisk/aehle/gcc/gcc-obj/../gcc-12.2.0/gcc/recog.cc:4406
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

We have attached:
- the stdout/stderr output with the additional flag -v,
- the preprocessed source produced with -freport-bug, 
- the files bug.i and bug.s produced with -save-temps.

The GCC 12.2.0 build was configured only with a --prefix option. gcc -v shows

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/ramdisk/aehle/gcc/gcc-install/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /ramdisk/aehle/gcc/gcc-obj/../gcc-12.2.0/configure
--prefix=/ramdisk/aehle/gcc/gcc-obj/../gcc-install
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.2.0 (GCC) 

uname -a says "Linux <hostname> 5.4.0-122-generic #138-Ubuntu SMP Wed Jun 22
15:00:31 UTC 2022 x86_64 GNU/Linux". /proc/cpuinfo shows a list of 96 cores
with the model name "AMD EPYC 7F72 24-Core Processor". All of the above
commands were executed in a Singularity container based on Debian 11.3.

The source file is a minimal example condensed from Valgrind's m_libcbase.c.

[Bug rtl-optimization/109276] ICE: in assign_stack_local_1, at function.cc:429 with -mpreferred-stack-boundary=2

[max.aehle at scicomp dot uni-kl.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109276

--- Comment #1 from Max Aehle <max.aehle at scicomp dot uni-kl.de> ---
Created attachment 54746
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54746&action=edit
source code of minimal example

[Bug rtl-optimization/109276] ICE: in assign_stack_local_1, at function.cc:429 with -mpreferred-stack-boundary=2

[max.aehle at scicomp dot uni-kl.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109276

--- Comment #2 from Max Aehle <max.aehle at scicomp dot uni-kl.de> ---
Created attachment 54747
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54747&action=edit
output with additional flag -v

[Bug rtl-optimization/109276] ICE: in assign_stack_local_1, at function.cc:429 with -mpreferred-stack-boundary=2

[max.aehle at scicomp dot uni-kl.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109276

--- Comment #3 from Max Aehle <max.aehle at scicomp dot uni-kl.de> ---
Created attachment 54748
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54748&action=edit
preprocessed source produced with -freport-bug

[Bug rtl-optimization/109276] ICE: in assign_stack_local_1, at function.cc:429 with -mpreferred-stack-boundary=2

[max.aehle at scicomp dot uni-kl.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109276

--- Comment #4 from Max Aehle <max.aehle at scicomp dot uni-kl.de> ---
Created attachment 54749
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54749&action=edit
produces with -save-temps

[Bug rtl-optimization/109276] ICE: in assign_stack_local_1, at function.cc:429 with -mpreferred-stack-boundary=2

[max.aehle at scicomp dot uni-kl.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109276

--- Comment #5 from Max Aehle <max.aehle at scicomp dot uni-kl.de> ---
Created attachment 54750
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54750&action=edit
produced with -save-temps

[Bug rtl-optimization/109276] ICE: in assign_stack_local_1, at function.cc:429 with -mpreferred-stack-boundary=2

[max.aehle at scicomp dot uni-kl.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109276

Max Aehle <max.aehle at scicomp dot uni-kl.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #54745|0                           |1
        is obsolete|                            |

--- Comment #6 from Max Aehle <max.aehle at scicomp dot uni-kl.de> ---
Comment on attachment 54745
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54745
verbose output, preprocessed source, .i and .s file

I submitted the zip archive because I though that only a single file could be
attached. Afterwards, I attached all files in the archive to this bug report
individually.

[Bug target/109276] [11/12/13 Regression] ICE: in assign_stack_local_1, at function.cc:429 with -mpreferred-stack-boundary=2

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109276

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to fail|                            |11.1.0, 13.0
            Summary|ICE: in                     |[11/12/13 Regression] ICE:
                   |assign_stack_local_1, at    |in assign_stack_local_1, at
                   |function.cc:429 with        |function.cc:429 with
                   |-mpreferred-stack-boundary= |-mpreferred-stack-boundary=
                   |2                           |2
   Target Milestone|---                         |11.4
           Keywords|                            |ice-on-valid-code
      Known to work|                            |10.1.0, 10.4.0, 9.5.0

[Bug target/109276] [11/12/13 Regression] ICE: in assign_stack_local_1, at function.cc:429 with -mpreferred-stack-boundary=2

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109276

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hjl.tools at gmail dot com,
                   |                            |jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
This started to ICE with r11-508-gdfa4fcdba374ed44 in the newly added pass
there,
and since r11-2259-g0a9d711df36b42b6494b73 it ICEs similarly like on the trunk.

[Bug target/109276] [11/12/13 Regression] ICE: in assign_stack_local_1, at function.cc:429 with -mpreferred-stack-boundary=2

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109276

--- Comment #8 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
A workaround is to do:
long long int digit __attribute__((aligned(8)));

Note manually setting the digit alignment to 4 does not cause an ICE for GCC
10.4 either.

[Bug target/109276] [11/12/13 Regression] ICE: in assign_stack_local_1, at function.cc:429 with -mpreferred-stack-boundary=2

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109276

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2023-03-24

--- Comment #9 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Confirmed.

[Bug target/109276] [11/12/13 Regression] ICE: in assign_stack_local_1, at function.cc:429 with -mpreferred-stack-boundary=2

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109276

--- Comment #10 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Jakub Jelinek from comment #7)
> This started to ICE with r11-508-gdfa4fcdba374ed44 in the newly added pass
> there,
> and since r11-2259-g0a9d711df36b42b6494b73 it ICEs similarly like on the
> trunk.

The new pass should just stack alignment requirements when alignment of
stack variable is increased.

[Bug target/109276] [11/12/13 Regression] ICE: in assign_stack_local_1, at function.cc:429 with -mpreferred-stack-boundary=2

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109276

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2

[Bug target/109276] [11/12/13 Regression] ICE: in assign_stack_local_1, at function.cc:429 with -mpreferred-stack-boundary=2

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109276

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Reduced testcase:
/* PR target/109276 */
/* { dg-do compile } */
/* { dg-options "-march=x86-64" } */
/* { dg-additional-options "-mpreferred-stack-boundary=2" } */

long long a;
long double b;

void
foo (void)
{
  b += a;
}

[Bug target/109276] [11/12/13 Regression] ICE: in assign_stack_local_1, at function.cc:429 with -mpreferred-stack-boundary=2

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109276

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The above testcase only started ICEing with r11-2259-g0a9d711df36b42b6494b73 ,
so I think the IPA pass is innocent here.

[Bug target/109276] [11/12/13 Regression] ICE: in assign_stack_local_1, at function.cc:429 with -mpreferred-stack-boundary=2

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109276

--- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Neither the new ix86_lower_local_decl_alignment function is called, nor
SET_DECL_ALIGN in pass_adjust_alignment::execute.
What happens is that
#0  ix86_local_alignment (exp=<integer_type 0x7fffea14b888 long long int>,
mode=E_DImode, align=64, may_lower=false) at
../../gcc/config/i386/i386.cc:17499
#1  0x0000000000883aab in get_stack_local_alignment (type=<integer_type
0x7fffea14b888 long long int>, mode=E_DImode) at ../../gcc/function.cc:290
#2  0x0000000000883d8c in assign_stack_local_1 (mode=E_DImode, size=...,
align=0, kind=2) at ../../gcc/function.cc:388
#3  0x000000000088457b in assign_stack_local (mode=E_DImode, size=..., align=0)
at ../../gcc/function.cc:547
#4  0x000000000120a3e7 in assign_386_stack_local (mode=E_DImode,
n=SLOT_FLOATxFDI_387) at ../../gcc/config/i386/i386.cc:16688
#5  0x0000000001b3c96f in gen_split_72 (curr_insn=0x7fffea1452c0,
operands=0x35183e0 <recog_data>) at ../../gcc/config/i386/i386.md:5723
#6  0x00000000021b7b7c in split_9 (x1=0x7fffea2fb6d8, insn=0x7fffea1452c0) at
../../gcc/config/i386/i386.md:5722
#7  0x000000000229f190 in split_insns (x1=0x7fffea2fb6d8, insn=0x7fffea1452c0)
at ../../gcc/config/i386/i386.md:16795
#8  0x000000000079c159 in try_split (pat=0x7fffea2fb6d8, trial=0x7fffea1452c0,
last=1) at ../../gcc/emit-rtl.cc:3799
asks for a DImode stack slot, ix86_local_alignment newly doesn't lower the
alignment
which isn't good for -mpreferred-stack-boundary=2.

[Bug target/109276] [11/12/13 Regression] ICE: in assign_stack_local_1, at function.cc:429 with -mpreferred-stack-boundary=2

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109276

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |jakub at gcc dot gnu.org
             Status|NEW                         |ASSIGNED

--- Comment #14 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 54769
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54769&action=edit
gcc13-pr109276.patch

So, I wonder if for the local DImode temporaries we just couldn't ask for
32-bit alignment with -m32 -mpreferred-stack-alignment=2.
I went through all the assign_386_stack_local calls which do or can pass DImode
to it:
- 2 spots in sync.md, both for a MEM scratch which I don't see a reason why it 
  couldn't be just 32-bit aligned, they are during expansion, SLOT_TEMP
- the SLOT_FLOATxFDI_387 use in the splitter used in this PR, that one also
  looks ok to be 32-bit aligned, during splitting
- floatunssi<mode>2 also during expansion, SLOT_TEMP, this one I'm afraid
really
  wants the slot to be 64-bit aligned
- in ix86_expand_divmod_libfunc SLOT_TEMP, also during expansion, I think
  that one would be ok to use 32-bit aligned
- scalar_chain::make_vector_copies and scalar_chain::convert_reg, during STV,
  SLOT_STV_TEMP, I think these want 64-bit alignment

[Bug target/109276] [11/12/13 Regression] ICE: in assign_stack_local_1, at function.cc:429 with -mpreferred-stack-boundary=2

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109276

--- Comment #15 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Jakub Jelinek from comment #13)
> asks for a DImode stack slot, ix86_local_alignment newly doesn't lower the
> alignment
> which isn't good for -mpreferred-stack-boundary=2.

IIRC, DImode FILD/FIST(P) instructions execute faster when memory is aligned to
64 bits. *If* it is possible, 64 bit alignment is preferred.

[Bug target/109276] [11/12/13 Regression] ICE: in assign_stack_local_1, at function.cc:429 with -mpreferred-stack-boundary=2

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109276

--- Comment #16 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Uroš Bizjak from comment #15)
> (In reply to Jakub Jelinek from comment #13)
> > asks for a DImode stack slot, ix86_local_alignment newly doesn't lower the
> > alignment
> > which isn't good for -mpreferred-stack-boundary=2.
> 
> IIRC, DImode FILD/FIST(P) instructions execute faster when memory is aligned
> to 64 bits. *If* it is possible, 64 bit alignment is preferred.

Well, user who uses -mpreferred-stack-boundary=2 probably doesn't care about
performance that much.  I guess I could also check whether we've already
decided to dynamically reallocate the stack for some other reasons and only use
32-bit alignment if we haven't.
But there are too many such flags, so not sure what to check.

[Bug target/109276] [11/12/13 Regression] ICE: in assign_stack_local_1, at function.cc:429 with -mpreferred-stack-boundary=2

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109276

--- Comment #17 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Jakub Jelinek from comment #16)
> (In reply to Uroš Bizjak from comment #15)
> > (In reply to Jakub Jelinek from comment #13)
> > > asks for a DImode stack slot, ix86_local_alignment newly doesn't lower the
> > > alignment
> > > which isn't good for -mpreferred-stack-boundary=2.
> > 
> > IIRC, DImode FILD/FIST(P) instructions execute faster when memory is aligned
> > to 64 bits. *If* it is possible, 64 bit alignment is preferred.
> 
> Well, user who uses -mpreferred-stack-boundary=2 probably doesn't care about
> performance that much.  I guess I could also check whether we've already
> decided to dynamically reallocate the stack for some other reasons and only
> use 32-bit alignment if we haven't.
> But there are too many such flags, so not sure what to check.

No need to complicate things too much, I agree that by using
-mpreferred-stack-boundary=2 user made a compromise w.r.t. performance.

[Bug target/109276] [11/12/13 Regression] ICE: in assign_stack_local_1, at function.cc:429 with -mpreferred-stack-boundary=2

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109276

--- Comment #18 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:4b5ef857f5faf09f274c0a95c67faaa80d198124

commit r13-6894-g4b5ef857f5faf09f274c0a95c67faaa80d198124
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue Mar 28 10:43:08 2023 +0200

    i386: Require just 32-bit alignment for SLOT_FLOATxFDI_387 -m32
-mpreferred-stack-boundary=2 DImode temporaries [PR109276]

    The following testcase ICEs since r11-2259 because assign_386_stack_local
    -> assign_stack_local -> ix86_local_alignment now uses 64-bit alignment
    for DImode temporaries rather than 32-bit as before.
    Most of the spots in the backend which ask for DImode temporaries are
during
    expansion and those apparently are handled fine with -m32
    -mpreferred-stack-boundary=2, we dynamically realign the stack in that case
    (most of the spots actually don't need that alignment but at least one
    does), then 2 spots are in STV which I assume also work correctly.
    But during splitting we can create a DImode slot which doesn't need to be
    64-bit alignment (it is nicer for performance though), when we apparently
    aren't able to detect it for dynamic stack realignment purposes.

    The following patch just makes the slot 32-bit aligned in that rare case.

    2023-03-28  Jakub Jelinek  <jakub@redhat.com>

            PR target/109276
            * config/i386/i386.cc (assign_386_stack_local): For DImode
            with SLOT_FLOATxFDI_387 and -m32 -mpreferred-stack-boundary=2 pass
            align 32 rather than 0 to assign_stack_local.

            * gcc.target/i386/pr109276.c: New test.

[Bug target/109276] [11/12 Regression] ICE: in assign_stack_local_1, at function.cc:429 with -mpreferred-stack-boundary=2

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109276

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[11/12/13 Regression] ICE:  |[11/12 Regression] ICE: in
                   |in assign_stack_local_1, at |assign_stack_local_1, at
                   |function.cc:429 with        |function.cc:429 with
                   |-mpreferred-stack-boundary= |-mpreferred-stack-boundary=
                   |2                           |2

--- Comment #19 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed on the trunk so far.

[Bug target/109276] [11/12 Regression] ICE: in assign_stack_local_1, at function.cc:429 with -mpreferred-stack-boundary=2

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109276

--- Comment #20 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-12 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:429a5143d17bd83d4662cd6c7a2c30d065c8f65b

commit r12-9423-g429a5143d17bd83d4662cd6c7a2c30d065c8f65b
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue Mar 28 10:43:08 2023 +0200

    i386: Require just 32-bit alignment for SLOT_FLOATxFDI_387 -m32
-mpreferred-stack-boundary=2 DImode temporaries [PR109276]

    The following testcase ICEs since r11-2259 because assign_386_stack_local
    -> assign_stack_local -> ix86_local_alignment now uses 64-bit alignment
    for DImode temporaries rather than 32-bit as before.
    Most of the spots in the backend which ask for DImode temporaries are
during
    expansion and those apparently are handled fine with -m32
    -mpreferred-stack-boundary=2, we dynamically realign the stack in that case
    (most of the spots actually don't need that alignment but at least one
    does), then 2 spots are in STV which I assume also work correctly.
    But during splitting we can create a DImode slot which doesn't need to be
    64-bit alignment (it is nicer for performance though), when we apparently
    aren't able to detect it for dynamic stack realignment purposes.

    The following patch just makes the slot 32-bit aligned in that rare case.

    2023-03-28  Jakub Jelinek  <jakub@redhat.com>

            PR target/109276
            * config/i386/i386.cc (assign_386_stack_local): For DImode
            with SLOT_FLOATxFDI_387 and -m32 -mpreferred-stack-boundary=2 pass
            align 32 rather than 0 to assign_stack_local.

            * gcc.target/i386/pr109276.c: New test.

    (cherry picked from commit 4b5ef857f5faf09f274c0a95c67faaa80d198124)

[Bug target/109276] [11 Regression] ICE: in assign_stack_local_1, at function.cc:429 with -mpreferred-stack-boundary=2

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109276

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[11/12 Regression] ICE: in  |[11 Regression] ICE: in
                   |assign_stack_local_1, at    |assign_stack_local_1, at
                   |function.cc:429 with        |function.cc:429 with
                   |-mpreferred-stack-boundary= |-mpreferred-stack-boundary=
                   |2                           |2

--- Comment #21 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed also for 12.3.

[Bug target/109276] [11 Regression] ICE: in assign_stack_local_1, at function.cc:429 with -mpreferred-stack-boundary=2

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109276

--- Comment #22 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:623245bc3f4eed25db80dd5f5650c18cd7314b39

commit r11-10731-g623245bc3f4eed25db80dd5f5650c18cd7314b39
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue Mar 28 10:43:08 2023 +0200

    i386: Require just 32-bit alignment for SLOT_FLOATxFDI_387 -m32
-mpreferred-stack-boundary=2 DImode temporaries [PR109276]

    The following testcase ICEs since r11-2259 because assign_386_stack_local
    -> assign_stack_local -> ix86_local_alignment now uses 64-bit alignment
    for DImode temporaries rather than 32-bit as before.
    Most of the spots in the backend which ask for DImode temporaries are
during
    expansion and those apparently are handled fine with -m32
    -mpreferred-stack-boundary=2, we dynamically realign the stack in that case
    (most of the spots actually don't need that alignment but at least one
    does), then 2 spots are in STV which I assume also work correctly.
    But during splitting we can create a DImode slot which doesn't need to be
    64-bit alignment (it is nicer for performance though), when we apparently
    aren't able to detect it for dynamic stack realignment purposes.

    The following patch just makes the slot 32-bit aligned in that rare case.

    2023-03-28  Jakub Jelinek  <jakub@redhat.com>

            PR target/109276
            * config/i386/i386.c (assign_386_stack_local): For DImode
            with SLOT_FLOATxFDI_387 and -m32 -mpreferred-stack-boundary=2 pass
            align 32 rather than 0 to assign_stack_local.

            * gcc.target/i386/pr109276.c: New test.

    (cherry picked from commit 4b5ef857f5faf09f274c0a95c67faaa80d198124)

[Bug target/109276] [11 Regression] ICE: in assign_stack_local_1, at function.cc:429 with -mpreferred-stack-boundary=2

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109276

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #23 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed for 11.4 as well.