[Bug middle-end/115459] New: [14/15 regression] Alpha/Linux ICE: in gen_rtx_SUBREG, at emit-rtl.cc:1032 around g-debpoo.adb:1896:8, as from r14-1187-gd6b756447cd5

[Bug middle-end/115459] New: [14/15 regression] Alpha/Linux ICE: in gen_rtx_SUBREG, at emit-rtl.cc:1032 around g-debpoo.adb:1896:8, as from r14-1187-gd6b756447cd5

[macro at orcam dot me.uk]

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

            Bug ID: 115459
           Summary: [14/15 regression] Alpha/Linux ICE: in gen_rtx_SUBREG,
                    at emit-rtl.cc:1032 around g-debpoo.adb:1896:8, as
                    from r14-1187-gd6b756447cd5
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Keywords: build, ice-on-valid-code
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: macro at orcam dot me.uk
                CC: aoliva at gcc dot gnu.org
  Target Milestone: ---
            Target: alpha-linux-gnu

Created attachment 58413
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58413&action=edit
reload: Do not emit a MEM SUBREG if it would break alignment rules

With alpha-linux-gnu target as from:

commit d6b756447cd58bcca20e6892790582308b869817
Author: Alexandre Oliva <oliva@adacore.com>
Date:   Wed May 24 03:07:56 2023 -0300

[PR100106] Reject unaligned subregs when strict alignment is required

I get:

during RTL pass: ira
+===========================GNAT BUG DETECTED==============================+
| 15.0.0 20240610 (experimental) (alpha-linux-gnu) GCC error:              |
| in gen_rtx_SUBREG, at emit-rtl.cc:1032                                   |
| Error detected around g-debpoo.adb:1896:8                                |
| Compiling g-debpoo.adb                                                   |
| Please submit a bug report; see https://gcc.gnu.org/bugs/ .              |
| Use a subject line meaningful to you and us to track the bug.            |
| Include the entire contents of this bug box in the report.               |
| Include the exact command that you entered.                              |
| Also include sources listed below.                                       |
+==========================================================================+

in libada; the invocation is:

.../obj/gcc/./gcc/xgcc -B.../obj/gcc/./gcc/ -B/usr/alpha-linux-gnu/bin/
-B/usr/alpha-linux-gnu/lib/ -isystem /usr/alpha-linux-gnu/include -isystem
/usr/alpha-linux-gnu/sys-include --sysroot=.../install/usr/sysroot  -c -g -O2
-fPIC -fno-lto -W -Wall -gnatpg -nostdinc -fno-toplevel-reorder  g-debpoo.adb
-o g-debpoo.o

And the triggering RTX is:

(mem:SI (plus:DI (reg/f:DI 15 $15)
        (const_int 8400 [0x20d0])) [0  S4 A8])

derived from:

(subreg:HI (mem:SI (plus:DI (reg/f:DI 63 FP)
            (const_int 8384 [0x20c0])) [0  S4 A8]) 0)

where the alignment of MEM is set to 8 for some reason (even though it's
SImode) and the alignment of HImode is of course 16.  Consequently the
newly added condition triggers and the assertion then fails.

AFAICT the MEM SUBREG RTX is made by combining:

(insn 1106 1110 1104 54 (set (reg:SI 769)
        (mem:SI (plus:DI (reg/f:DI 63 FP)
                (const_int 8384 [0x20c0])) [0  S4 A8])) "g-debpoo.adb":1861:21
discrim 2 213 {*movsi}
     (nil))

and:

(insn 1112 1105 1723 54 (set (subreg:DI (reg:SI 771) 0)
        (zero_extend:DI (subreg:HI (reg:SI 769) 0))) "g-debpoo.adb":1861:21
discrim 2 52 {zero_extendhidi2}
     (expr_list:REG_DEAD (reg:SI 769)
        (nil)))

into one, which is shown as (with the SET destination set to NIL, likely
due to the in-progress state at the time of the assertion):

(insn 1112 1111 1723 54 (set (nil)
        (zero_extend:DI (subreg:HI (mem:SI (plus:DI (reg/f:DI 63 FP)
                        (const_int 8384 [0x20c0])) [0  S4 A8]) 0)))
"g-debpoo.adb":1861:21 discrim 2 52 {zero_extendhidi2}
     (nil))

I have attached a patch that fixes the issue for me, by preventing the
combined MEM subreg from being created.  It's still in testing and I'm
not sure offhand if it's the best or even the correct one.

I note this is with a !TARGET_BWX target (using `-mcpu=ev4' default), so
it's not clear to me why the `reg_or_bwx_memory_operand' predicate has
allowed such a combined operand in the first place, but maybe SUBREGs are
special.  For the record it doesn't trigger with TARGET_BWX targets, e.g.
`-mcpu=ev56'.

I also note that Alpha is still !LRA; I've thought a RISC target would be
easy to convert.  For the time being this issue needs to be fixed though.

[Bug middle-end/115459] [15 regression] Alpha/Linux ICE: in gen_rtx_SUBREG, at emit-rtl.cc:1032 around g-debpoo.adb:1896:8, as from r14-1187-gd6b756447cd5

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|14.0                        |15.0
            Summary|[14/15 regression]          |[15 regression] Alpha/Linux
                   |Alpha/Linux ICE: in         |ICE: in gen_rtx_SUBREG, at
                   |gen_rtx_SUBREG, at          |emit-rtl.cc:1032 around
                   |emit-rtl.cc:1032 around     |g-debpoo.adb:1896:8, as
                   |g-debpoo.adb:1896:8, as     |from r14-1187-gd6b756447cd5
                   |from r14-1187-gd6b756447cd5 |
   Target Milestone|---                         |15.0

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
The change doesn't seem to be on the GCC 14 branch.

[Bug middle-end/115459] [14/15 regression] Alpha/Linux ICE: in gen_rtx_SUBREG, at emit-rtl.cc:1032 around g-debpoo.adb:1896:8, as from r14-1187-gd6b756447cd5

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|15.0                        |14.2

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #1)
> The change doesn't seem to be on the GCC 14 branch.

r14-1187-gd6b756447cd58b is the commit id where the change was done for
rejecting `unaligned subregs when strict alignment`.

[Bug middle-end/115459] [14/15 regression] Alpha/Linux ICE: in gen_rtx_SUBREG, at emit-rtl.cc:1032 around g-debpoo.adb:1896:8, as from r14-1187-gd6b756447cd5

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Alpha really should move to LRA too.

[Bug middle-end/115459] [14/15 regression] Alpha/Linux ICE: in gen_rtx_SUBREG, at emit-rtl.cc:1032 around g-debpoo.adb:1896:8, as from r14-1187-gd6b756447cd5

[macro at orcam dot me.uk]

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

--- Comment #4 from Maciej W. Rozycki <macro at orcam dot me.uk> ---
(In reply to Andrew Pinski from comment #3)
> Alpha really should move to LRA too.

I can certainly have a look once I'm done with the VAX target unless
someone beats me to it.  Or maybe even before, as I have an important
matter to sort out with the Alpha target now.  We shall see.

[Bug middle-end/115459] [14/15 regression] Alpha/Linux ICE: in gen_rtx_SUBREG, at emit-rtl.cc:1032 around g-debpoo.adb:1896:8, as from r14-1187-gd6b756447cd5

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva <aoliva at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2024-06-13
             Status|UNCONFIRMED                 |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |aoliva at gcc dot gnu.org

--- Comment #5 from Alexandre Oliva <aoliva at gcc dot gnu.org> ---
Created attachment 58417
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58417&action=edit
candidate patch

Mine.  Here's a patch that seems to avoid the problem at the root.