[Bug target/113115] New: ICE In extract_constrain_insn_cached recog.cc with ppc64le-linux-gnu crosscompiler

[Bug target/113115] New: ICE In extract_constrain_insn_cached recog.cc with ppc64le-linux-gnu crosscompiler

[fkastl at suse dot cz]

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

            Bug ID: 113115
           Summary: ICE In extract_constrain_insn_cached recog.cc with
                    ppc64le-linux-gnu crosscompiler
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Keywords: ice-on-valid-code, needs-bisection
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: fkastl at suse dot cz
  Target Milestone: ---
              Host: x86_64-pc-linux-gnu
            Target: ppc64le-linux-gnu

While compiling the GCC testcase gcc.target/powerpc/pr103627-3.c with the
ppc64le crosscompiler the with these options:

ppc64le-linux-gnu-gcc
/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gcc.target/powerpc/pr103627-3.c
-mno-power8-vector

the compiler runs into an ICE

/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gcc.target/powerpc/pr103627-3.c:
In function ‘main’:
/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gcc.target/powerpc/pr103627-3.c:19:1:
error: insn does not satisfy its constraints:
   19 | }
      | ^
(insn 55 54 56 (set (reg:OO 32 0)
        (mem/c:OO (plus:DI (reg/f:DI 9 9 [128])
                (const_int 32 [0x20])) [2 c+32 S32 A256]))
"/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gcc.target/powerpc/pr103627-3.c":12:1
2172 {*movoo}
     (nil))
during RTL pass: shorten
/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gcc.target/powerpc/pr103627-3.c:19:1:
internal compiler error: in extract_constrain_insn_cached, at recog.cc:2725
0x654383 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
       
/home/worker/buildworker/tiber-gcc-trunk-ppc64le/build/gcc/rtl-error.cc:108
0x6543a9 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
       
/home/worker/buildworker/tiber-gcc-trunk-ppc64le/build/gcc/rtl-error.cc:118
0x6538ee extract_constrain_insn_cached(rtx_insn*)
       
/home/worker/buildworker/tiber-gcc-trunk-ppc64le/build/gcc/recog.cc:2725
0x1352337 insn_default_length(rtx_insn*)
       
/home/worker/buildworker/tiber-gcc-trunk-ppc64le/build/gcc/config/rs6000/rs6000.md:15156
0x8eada2 shorten_branches(rtx_insn*)
       
/home/worker/buildworker/tiber-gcc-trunk-ppc64le/build/gcc/final.cc:1089
0x8eaddf rest_of_handle_shorten_branches
       
/home/worker/buildworker/tiber-gcc-trunk-ppc64le/build/gcc/final.cc:4338
0x8eaddf execute
       
/home/worker/buildworker/tiber-gcc-trunk-ppc64le/build/gcc/final.cc:4367
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.


Compiler configuration:

Using built-in specs.
COLLECT_GCC=/home/worker/cross/bin/ppc64le-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/home/worker/cross/libexec/gcc/ppc64le-linux-gnu/14.0.0/lto-wrapper
Target: ppc64le-linux-gnu
Configured with:
/home/worker/buildworker/tiber-gcc-trunk-ppc64le/build/configure
--enable-languages=c,c++,fortran,rust,m2 --disable-bootstrap
--disable-libsanitizer --disable-multilib --enable-checking=release
--prefix=/home/worker/cross --target=ppc64le-linux-gnu
--with-as=/usr/bin/powerpc64le-suse-linux-as
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231221 (experimental)
ec2ec24a4d4d1175f72641a95010c2312eb38ccd (GCC)

[Bug target/113115] ICE In extract_constrain_insn_cached recog.cc with ppc64le-linux-gnu crosscompiler

[mjires at suse dot cz]

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

Michal Jireš <mjires at suse dot cz> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jeevitha at gcc dot gnu.org,
                   |                            |mjires at suse dot cz

--- Comment #1 from Michal Jireš <mjires at suse dot cz> ---
Bisected to r14-3592-g9ea1248604d7b6.

[Bug target/113115] [14 Regression] ICE In extract_constrain_insn_cached recog.cc with ppc64le-linux-gnu crosscompiler from r14-3592-g9ea1248604d7b6

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |14.0

[Bug target/113115] [14 Regression] ICE In extract_constrain_insn_cached recog.cc with ppc64le-linux-gnu crosscompiler from r14-3592-g9ea1248604d7b6

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2024-01-08
           Priority|P3                          |P1
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed by bisection.

[Bug target/113115] [14 Regression] ICE In extract_constrain_insn_cached recog.cc with ppc64le-linux-gnu crosscompiler from r14-3592-g9ea1248604d7b6

[bergner at gcc dot gnu.org]

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

Peter Bergner <bergner at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bergner at gcc dot gnu.org,
                   |                            |dje at gcc dot gnu.org,
                   |                            |linkw at gcc dot gnu.org,
                   |                            |segher at gcc dot gnu.org

--- Comment #3 from Peter Bergner <bergner at gcc dot gnu.org> ---
Ke Wen, is this just a duplicate of PR109987 and PR103627?  I know it was
bisected to Jeevitha's commit, but it seems more like her commit exposed the
same latent issue as those other PRs, rather than causing it.  Your thoughts?

[Bug target/113115] [14 Regression] ICE In extract_constrain_insn_cached recog.cc with ppc64le-linux-gnu crosscompiler from r14-3592-g9ea1248604d7b6

[linkw at gcc dot gnu.org]

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

Kewen Lin <linkw at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |DUPLICATE

--- Comment #4 from Kewen Lin <linkw at gcc dot gnu.org> ---
(In reply to Peter Bergner from comment #3)
> Ke Wen, is this just a duplicate of PR109987 and PR103627?  I know it was
> bisected to Jeevitha's commit, but it seems more like her commit exposed the
> same latent issue as those other PRs, rather than causing it.  Your thoughts?

Yes, I agree it's duplicated of PR109987, Jeevitha's commit just exposed this
known issue, since we are in stage 3, I wonder if we can go with power9-vector
guarding first
(https://gcc.gnu.org/pipermail/gcc-patches/2021-December/587310.html) since
power9-vector still exists in this release, and we can try to remove these
workaround options in next release. (Sorry that I missed to follow up the
power{8,9}-vector removal)

*** This bug has been marked as a duplicate of bug 109987 ***

[Bug target/113115] [14 Regression] ICE In extract_constrain_insn_cached recog.cc with ppc64le-linux-gnu crosscompiler from r14-3592-g9ea1248604d7b6

[bergner at gcc dot gnu.org]

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

--- Comment #5 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Kewen Lin from comment #4)
> Yes, I agree it's duplicated of PR109987, Jeevitha's commit just exposed
> this known issue, since we are in stage 3, I wonder if we can go with
> power9-vector guarding first
> (https://gcc.gnu.org/pipermail/gcc-patches/2021-December/587310.html) since
> power9-vector still exists in this release, and we can try to remove these
> workaround options in next release. (Sorry that I missed to follow up the
> power{8,9}-vector removal)

I really dislike the -mpower{8,9}-vector options, but maybe it's too late to
remove them for this release?  I'm not sure how involved/invasive that patch
would be.  Segher, do you have a preference on remove them now or use the
workaround above and remove in the next release?

[Bug target/113115] [14 Regression] ICE In extract_constrain_insn_cached recog.cc with ppc64le-linux-gnu crosscompiler from r14-3592-g9ea1248604d7b6

[segher at gcc dot gnu.org]

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

--- Comment #6 from Segher Boessenkool <segher at gcc dot gnu.org> ---
Using -mpower9-vector while not having -mcpu=power9 (or later) is wrong, and
should
not work.  Using -mno-power9-vector is just weird.

If we can neuter the -mpower9-vector (etc.) options now, that would be good. 
But
there are some complications with the testsuite at least?

[Bug target/113115] [14 Regression] ICE In extract_constrain_insn_cached recog.cc with ppc64le-linux-gnu crosscompiler from r14-3592-g9ea1248604d7b6

[linkw at gcc dot gnu.org]

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

--- Comment #7 from Kewen Lin <linkw at gcc dot gnu.org> ---
(In reply to Peter Bergner from comment #5)
> I really dislike the -mpower{8,9}-vector options, but maybe it's too late to
> remove them for this release?  I'm not sure how involved/invasive that patch
> would be.  Segher, do you have a preference on remove them now or use the
> workaround above and remove in the next release?

(In reply to Segher Boessenkool from comment #6)
> Using -mpower9-vector while not having -mcpu=power9 (or later) is wrong, and
> should
> not work.  Using -mno-power9-vector is just weird.
> 
> If we can neuter the -mpower9-vector (etc.) options now, that would be good.
> But
> there are some complications with the testsuite at least?

OK, it sounds that it's still acceptable to adjust this at this time point, so
I'm working on a patch to evaluate its impact, will post it after full testing.