[Bug go/94611] New: gccgo hangs (infinite loop) on complex projects, seemingly in simplify-rtx.c/simplify_plus_minus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94611 Bug ID: 94611 Summary: gccgo hangs (infinite loop) on complex projects, seemingly in simplify-rtx.c/simplify_plus_minus Product: gcc Version: 9.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: gcc at octaforge dot org CC: cmang at google dot com Target Milestone: --- Created attachment 48283 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48283&action=edit debugger steps Attempting to compile complicated projects, such as bootstrapping the official Go compiler (regardless of version), using gccgo will result in the gc1 process entering infinite loop. Configuration: - GCC 9.3.0 (as far as I know, all 9.x series are known to do this, but I had it work on some version of 8.x some time ago) - ppc64le architecture (seems to affect at very least all other PowerPC) - Linux The gc1 process will keep running forever and keep growing in RSS. By attaching into the process, I was able to narrow it down to 'simplify_plus_minus' from simplify-rtx.c. Unfortunately, I wasn't able to isolate a trivial test case. It seems to happen when building any sufficiently complex project. Trivial things build alright, and gccgo can also bootstrap itself (when building a cross-toolchain). I've never seen this happen with C/C++, so I suspect the gccgo frontend is generating bogus data that the backend can't process. Attached is the debugger output stepping through the call, one whole iteration, on GCC 9.3.0.
[Bug target/94611] gccgo hangs (infinite loop) on complex projects, seemingly in simplify-rtx.c/simplify_plus_minus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94611 --- Comment #2 from Daniel Kolesa --- It reproduces on any GCC 9.x series, and when building *any* version of the official Go compiler (tested 1.12-1.14), and many other projects (e.g. gitea). I'm not sure if it reproduces on x86_64, as I don't have any machines to test that on available right now (I can test that later). If I knew a specific revision of gcc in which it started happening, I would've patched it myself, but bisecting several years worth of gcc development is a bit outside of the free time I have available right now. Unfortunately I generally don't use Go, so isolating a test case is harder for me than for other things
[Bug target/94611] gccgo hangs (infinite loop) on complex projects, seemingly in simplify-rtx.c/simplify_plus_minus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94611 --- Comment #3 from Daniel Kolesa --- The steps I took to reproduce the problem: 1) Grab a Go source release 2) Install gccgo including the 'go' command 3) Then do something like: cd go-1.x export GOROOT_BOOTSTRAP=/usr/lib/go/9.3.0 export GOROOT=$PWD export GOROOT_FINAL=/usr/lib/go export GOARCH=ppc64le # or amd64, or ... cd src bash make.bash --no-clean -v The build will run for a while. Apparently the command that hangs is: /usr/bin/gccgo -c -O2 -g -fdebug-prefix-map=/tmp/go-build771879105=/tmp/go-build -gno-record-gcc-switches -fgo-pkgpath=bootstrap/cmd/internal/obj/x86 -o /tmp/go-build771879105/b032/_go_.o -I /tmp/go-build771879105/b032/_importcfgroot_ /home/q66/go/pkg/bootstrap/src/bootstrap/cmd/internal/obj/x86/a.out.go /home/q66/go/pkg/bootstrap/src/bootstrap/cmd/internal/obj/x86/aenum.go /home/q66/go/pkg/bootstrap/src/bootstrap/cmd/internal/obj/x86/anames.go /home/q66/go/pkg/bootstrap/src/bootstrap/cmd/internal/obj/x86/asm6.go /home/q66/go/pkg/bootstrap/src/bootstrap/cmd/internal/obj/x86/avx_optabs.go /home/q66/go/pkg/bootstrap/src/bootstrap/cmd/internal/obj/x86/evex.go /home/q66/go/pkg/bootstrap/src/bootstrap/cmd/internal/obj/x86/list6.go /home/q66/go/pkg/bootstrap/src/bootstrap/cmd/internal/obj/x86/obj6.go /home/q66/go/pkg/bootstrap/src/bootstrap/cmd/internal/obj/x86/ytab.go
[Bug target/94611] gccgo hangs (infinite loop) on complex projects, seemingly in simplify-rtx.c/simplify_plus_minus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94611 --- Comment #4 from Daniel Kolesa --- Oh, also, sorry, the process that *actually* gets stuck is go1, not gc1, that was a typo.
[Bug target/94611] gccgo hangs (infinite loop) on complex projects, seemingly in simplify-rtx.c/simplify_plus_minus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94611 Daniel Kolesa changed: What|Removed |Added Target|powerpc64le-linux-gnu | --- Comment #5 from Daniel Kolesa --- okay, I can reproduce this hanging on x86_64 as well. It does not loop in the same place though, but instead in alias.c, around true_dependence_1.
[Bug target/94611] gccgo hangs (infinite loop) on complex projects, seemingly in simplify-rtx.c/simplify_plus_minus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94611 --- Comment #6 from Daniel Kolesa --- Another thing of note, the gccgo command that hangs is the same on both x86_64 and ppc64le
[Bug target/94611] gccgo hangs (infinite loop) on complex projects, seemingly in simplify-rtx.c/simplify_plus_minus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94611 Daniel Kolesa changed: What|Removed |Added Target||ppc64le-linux-gnu --- Comment #7 from Daniel Kolesa --- more observations: the x86_64 build does eventually finish (though it takes a while), so it's probably not the same thing.
[Bug target/94611] gccgo hangs (infinite loop) on complex projects, seemingly in simplify-rtx.c/simplify_plus_minus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94611 --- Comment #9 from Daniel Kolesa --- it finishes with -fno-var-tracking, though it does take up a few gigs of memory and takes a while, this is consistent with the default behavior on x86_64 where it does the same thing.
[Bug c/91920] ggc 9.2.0 failing openmp compile on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91920 Daniel Kolesa changed: What|Removed |Added CC||gcc at octaforge dot org --- Comment #2 from Daniel Kolesa --- confirmed, same here
[Bug middle-end/91920] ggc 9.2.0 failing openmp compile on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91920 --- Comment #4 from Daniel Kolesa --- Yeah, the testcase doesn't really matter, AFAIK the purpose here was just to provide something that fails in the same way as darktable (which is the project where this bug shows up).
[Bug target/91135] New: __linux__ not defined with -mcall-aixdesc on 9.x and ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91135 Bug ID: 91135 Summary: __linux__ not defined with -mcall-aixdesc on 9.x and ppc64 Product: gcc Version: 9.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: gcc at octaforge dot org Target Milestone: --- Since 9.x, using the `-mcall-aixdesc` makes gcc undefine `__linux__`. This breaks compilation of the Linux kernel as it relies on the older behavior (`-mcall-aixdesc` is used on BE, without it the kernel does not link and there are several modules that check for `__linux__` being defined and break if it's not). The kernel claims it's a GCC bug: https://bugzilla.kernel.org/show_bug.cgi?id=204125 Could someone confirm whether it is, so that it is known if this needs to be fixed in gcc or in the kernel? Thanks
[Bug target/91135] [9/10 Regression] __linux__ not defined with -mcall-aixdesc on 9.x and ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91135 --- Comment #3 from Daniel Kolesa --- Yeah, I noticed as much while investigating this. Question is, should gcc define it? Is it the kernel that is in the wrong here as I originally thought?
[Bug target/91135] [9/10 Regression] __linux__ not defined with -mcall-aixdesc on 9.x and ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91135 --- Comment #5 from Daniel Kolesa --- I don't know 100% *what* the kernel uses it for, I just know it does. If I remove it, linking vmlinux fails (with thousands of undefined references) so it seems to require that specific ABI for whatever reason; my best guess is that it requires the symbol names to be emitted with a dot, and it won't without that flag, but I might as well be wrong.
[Bug target/91135] [9/10 Regression] __linux__ not defined with -mcall-aixdesc on 9.x and ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91135 --- Comment #7 from Daniel Kolesa --- The actual reason why the linkage fails without the flag, for anyone interested https://bugzilla.kernel.org/show_bug.cgi?id=204125#c6
[Bug libstdc++/111129] New: std::regex incorrectly matches quantifiers with plus appended
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29
Bug ID: 29
Summary: std::regex incorrectly matches quantifiers with plus
appended
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc at octaforge dot org
Target Milestone: ---
Example code:
```
#include
#include
#include
int main(void) {
std::smatch matches;
auto re = std::regex(R"(a++)", std::regex::icase);
std::string inp = "aaa";
std::regex_search(inp, matches, re);
for (auto &match: matches) {
printf("%s\n", match.str().data());
}
}
```
With libstdc++, this does not crash, and outputs 'aaa'.
This gives people a false idea that libstdc++ implements possessive quantifiers
(see e.g. https://github.com/wwmm/easyeffects/pull/2536) despite the
documentation or code having no references to any such extension (and the C++
standard likewise not mentioning it). You can verify that the semantics are not
possessive by changing the pattern to 'a++a', which should with possessive
semantics not match anything, but with libstdc++ it's an identical match as
before.
With libc++, this correctly fails with: libc++abi: terminating due to uncaught
exception of type std::__1::regex_error: One of *?+{ was not preceded by a
valid regular expression.
[Bug bootstrap/113174] New: gcc fails to bootstrap on pp64le with clang-based host environment (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113174 Bug ID: 113174 Summary: gcc fails to bootstrap on pp64le with clang-based host environment (internal compiler error) Product: gcc Version: 13.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: gcc at octaforge dot org Target Milestone: --- Attempting to bootstrap GCC on Chimera Linux (https://chimera-linux.org) which uses LLVM/Clang as its system compiler and runtime fails, presumably inside the stage 1 compiler, with an internal compiler error. Backtrace from cc1plus, full build logs (gcc-build.log is the original build run, gcc-build2.log is after resumption), as well as the -dap output for the affected file is available here: https://ftp.octaforge.org/q66/random/gcc-out/ Packaging and patches available here: https://github.com/chimera-linux/cports/tree/master/experimental/gcc In particular, configure arguments are listed at https://github.com/chimera-linux/cports/blob/master/experimental/gcc/template.py#L11 and at https://github.com/chimera-linux/cports/blob/master/experimental/gcc/template.py#L123 , for ppc64le. Apologies for the potentially verbose script. The patches are almost entirely taken from Alpine Linux (which supports ppc64le and seemingly builds fine) outside of my patches that enforce defaulting to compiler-rt runtime instead of libgcc (libclang_rt.builtins + libunwind) and libc++ in place of libstdc++ to match the system toolchain (as otherwise gcc would generate incompatible binaries in this environment). I believe those should not affect this ICE (as this happens during object file generation), or at least I have no idea of the mechanism if they do. Observations: 1) passing -fno-tree-ter will prevent most of the crashes (and it was passed during the build above, mistakenly as I had not intended to pass it) but it eventually crashes anyway (it just does so later; I have verified that the backtraces are identical, so regardless of -fno-tree-ter the same issue is triggered) 2) the insn-recog.cc differs quite a bit for gcc-prev and gcc (diff: https://0x0.st/HEt-.diff), the function that segfaults in the backtrace notably is changed; I'm not entirely sure why 3) I'm not sure if this is just the stage 1 compiler crashing or if subsequent stages are affected; to me from the output it looks like this is still stage 1, however I tried all sorts of combinations of flags (including STAGE1_TFLAGS) without success 4) I tested other targets (x86_64 and aarch64) which work fine. The issue appears to be isolated to rs6000, and quite possibly ppc64le only, as it appears to deal with VSX. However, I had not been able to test this on ppc64 big endian yet. Please let me know if any other information is needed from me. I believe a preprocessed source file is probably not helpful as the issue only reproduces with a particular compiler build for a pretty random set of inputs. I was hoping to figure this out by myself, however I am not familiar enough with GCC's design and internals to make a good sense of this. Apologies if the information is incomplete or if this is an issue with my configuration in some way.
[Bug bootstrap/113174] gcc fails to bootstrap on pp64le with clang-based host environment (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113174 --- Comment #3 from Daniel Kolesa --- this is the preprocessed source: https://0x0.st/HEt7.ii It's generated with the following command line: /builddir/gcc-13.2.1_git20231014/build/./prev-gcc/xg++ -B/builddir/gcc-13.2.1_git20231014/build/./prev-gcc/ -B/usr/powerpc64le-chimera-linux-musl/bin/ -nostdinc++ -B/builddir/gcc-13.2.1_git20231014/build/prev-powerpc64le-chimera-linux-musl/libstdc++-v3/src/.libs -B/builddir/gcc-13.2.1_git20231014/build/prev-powerpc64le-chimera-linux-musl/libstdc++-v3/libsupc++/.libs -I/builddir/gcc-13.2.1_git20231014/build/prev-powerpc64le-chimera-linux-musl/libstdc++-v3/include/powerpc64le-chimera-linux-musl -I/builddir/gcc-13.2.1_git20231014/build/prev-powerpc64le-chimera-linux-musl/libstdc++-v3/include -I/builddir/gcc-13.2.1_git20231014/libstdc++-v3/libsupc++ -L/builddir/gcc-13.2.1_git20231014/build/prev-powerpc64le-chimera-linux-musl/libstdc++-v3/src/.libs -L/builddir/gcc-13.2.1_git20231014/build/prev-powerpc64le-chimera-linux-musl/libstdc++-v3/libsupc++/.libs -fno-PIE -c -g -O2 -fno-checking -fno-tree-ter -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Wconditionally-supported -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -I. -I. -I/builddir/gcc-13.2.1_git20231014/gcc -I/builddir/gcc-13.2.1_git20231014/gcc/. -I/builddir/gcc-13.2.1_git20231014/gcc/../include -I/builddir/gcc-13.2.1_git20231014/gcc/../libcpp/include -I/builddir/gcc-13.2.1_git20231014/gcc/../libcody -Iyes/include -Iyes/include -Iyes/include -I/builddir/gcc-13.2.1_git20231014/gcc/../libdecnumber -I/builddir/gcc-13.2.1_git20231014/gcc/../libdecnumber/dpd -I../libdecnumber -I/builddir/gcc-13.2.1_git20231014/gcc/../libbacktrace -o modulo-sched.o -MT modulo-sched.o -MMD -MP -MF ./.deps/modulo-sched.TPo /builddir/gcc-13.2.1_git20231014/gcc/modulo-sched.cc The command line is taken from the failing log. Yes, it could be an LLVM bug. It's hard to say whether it is though.
[Bug bootstrap/113174] gcc fails to bootstrap on pp64le with clang-based host environment (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113174 --- Comment #4 from Daniel Kolesa --- I don't think builds with completely unchanged source are going to work, as the compiler won't even reach this point then (at very least several of them are necessary for stage 1 to build at all)
[Bug bootstrap/113174] gcc fails to bootstrap on pp64le with clang-based host environment (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113174
--- Comment #6 from Daniel Kolesa ---
If it helps, I have reduced the patches to just the two that strictly necessary
for stage 1 build (I can't get rid of those, sorry, that would be asking for
the impossible), which are:
https://github.com/chimera-linux/cports/blob/master/experimental/gcc/patches/clang-tree-vect.patch
https://github.com/chimera-linux/cports/blob/master/experimental/gcc/patches/clang17.patch
and reproduced the exact same segfault on the same files with the exact same
backtrace.
Therefore, I can safely conclude that the patches are 100% irrelevant to the
problem at hand, as the two remaining ones are merely small build fixes.
--
libtool: compile: /builddir/gcc-13.2.1_git20231014/build/./gcc/xgcc
-shared-libgcc -B/builddir/gcc-13.2.1_git20231014/build/./gcc -nostdinc++
-L/builddir/gcc-13.2.1_git20231014/build/powerpc64le-chimera-linux-musl/libstdc++-v3/src
-L/builddir/gcc-13.2.1_git20231014/build/powerpc64le-chimera-linux-musl/libstdc++-v3/src/.libs
-L/builddir/gcc-13.2.1_git20231014/build/powerpc64le-chimera-linux-musl/libstdc++-v3/libsupc++/.libs
-B/usr/powerpc64le-chimera-linux-musl/bin/
-B/usr/powerpc64le-chimera-linux-musl/lib/ -isystem
/usr/powerpc64le-chimera-linux-musl/include -isystem
/usr/powerpc64le-chimera-linux-musl/sys-include -fno-checking
-I/builddir/gcc-13.2.1_git20231014/libstdc++-v3/../libgcc
-I/builddir/gcc-13.2.1_git20231014/build/powerpc64le-chimera-linux-musl/libstdc++-v3/include/powerpc64le-chimera-linux-musl
-I/builddir/gcc-13.2.1_git20231014/build/powerpc64le-chimera-linux-musl/libstdc++-v3/include
-I/builddir/gcc-13.2.1_git20231014/libstdc++-v3/libsupc++ -std=gnu++17
-nostdinc++ -D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra
-Wwrite-strings -Wcast-qual -Wabi=2 -fdiagnostics-show-location=once
-ffunction-sections -fdata-sections -frandom-seed=floating_from_chars.lo
-fimplicit-templates -fstack-clash-protection -mtune=power9 -O2
-ffile-prefix-map=/builddir/gcc-13.2.1_git20231014=. -g2 -D_GNU_SOURCE -c
/builddir/gcc-13.2.1_git20231014/libstdc++-v3/src/c++17/floating_from_chars.cc
-fPIC -DPIC -D_GLIBCXX_SHARED -o floating_from_chars.o
during RTL pass: combine
In file included from
/builddir/gcc-13.2.1_git20231014/libstdc++-v3/src/c++17/floating_from_chars.cc:86:
/builddir/gcc-13.2.1_git20231014/libstdc++-v3/src/c++17/fast_float/fast_float.h:
In function '{anonymous}::fast_float::adjusted_mantissa
{anonymous}::fast_float::digit_comp(parsed_number_string&, adjusted_mantissa)
[with T = float]':
/builddir/gcc-13.2.1_git20231014/libstdc++-v3/src/c++17/fast_float/fast_float.h:2850:1:
internal compiler error: Segmentation fault
2850 | }
| ^
0x1279a323 crash_signal(int)
/builddir/gcc-13.2.1_git20231014/gcc/toplev.cc:314
cc1plus:
/builddir/gcc-13.2.1_git20231014/build/./gcc/cc1plus -quiet -nostdinc++
-nostdinc++ -v -I /builddir/gcc-13.2.1_git20231014/libstdc++-v3/../libgcc -I
/builddir/gcc-13.2.1_git20231014/build/powerpc64le-chimera-linux-musl/libstdc++-v3/include/powerpc64le-chimera-linux-musl
-I
/builddir/gcc-13.2.1_git20231014/build/powerpc64le-chimera-linux-musl/libstdc++-v3/include
-I /builddir/gcc-13.2.1_git20231014/libstdc++-v3/libsupc++ -iprefix
/builddir/gcc-13.2.1_git20231014/build/gcc/../lib/gcc/powerpc64le-chimera-linux-musl/13.2.1/
-isystem /builddir/gcc-13.2.1_git20231014/build/./gcc/include -isystem
/builddir/gcc-13.2.1_git20231014/build/./gcc/include-fixed -D_GNU_SOURCE -D
_GLIBCXX_SHARED -D _GNU_SOURCE -D PIC -D _GLIBCXX_SHARED -isystem
/usr/powerpc64le-chimera-linux-musl/include -isystem
/usr/powerpc64le-chimera-linux-musl/sys-include
/builddir/gcc-13.2.1_git20231014/libstdc++-v3/src/c++17/floating_from_chars.cc
-msecure-plt -quiet -dumpbase floating_from_chars.cc -dumpbase-ext .cc
-mtune=power9 -mabi=elfv2 -g2 -O2 -Wall -Wextra -Wwrite-strings -Wcast-qual
-Wabi=2 -std=gnu++17 -version -fno-checking -fdiagnostics-show-location=once
-ffunction-sections -fdata-sections -frandom-seed=floating_from_chars.lo
-fimplicit-templates -fstack-clash-protection
-ffile-prefix-map=/builddir/gcc-13.2.1_git20231014=. -fPIC -o /tmp/ccLDfChm.s
backtrace:
* thread #1, name = 'cc1plus', stop reason = signal SIGSEGV: address not mapped
to object (fault address: 0x10062)
frame #0: 0x115b750c cc1plus`recog_114(x1=0x3fffe897a5a0,
insn=0x3fffe8979b00, pnum_clobbers=0x3fffda0c) at rs6000.md:8019:7
8016li %0,%1
8017mf%1 %0
8018mt%0 %1
-> 8019lwz%U1%X1 %0,%1
8020stw%U0%X0 %1,%0"
8021 [(set_attr_alternative "type"
8022 [(const_string "cr_logical")
(lldb) bt
* thread #1, name = 'cc1plus', stop reason = signal SIGSEGV: address not mapped
to object (fault address: 0x10062)
* frame #0: 0x115b750c cc1plus`recog_114(x1=0x3fffe897a5a0,
insn=0x3fffe8979b00, pnum_clobbers=0x3fffda0c) at rs6000.md:8019:7
frame #1: 0x1154aa50 cc1plus`recog_126(x1=0x3fffe897a5a0,
insn=0x3fffe8979b00
[Bug bootstrap/113174] gcc fails to bootstrap on pp64le with clang-based host environment (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113174 --- Comment #7 from Daniel Kolesa --- I just tested this on big-endian ppc64 targeting power4/ppc970; I was able to successfully bootstrap the compiler. It seems this is really specific to LE after all (which makes sense I suppose, considering the affected code appears to be related to VSX?)
[Bug bootstrap/113174] gcc fails to bootstrap on pp64le with clang-based host environment (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113174
--- Comment #8 from Daniel Kolesa ---
I tried an experiment: I canceled the build after initial generation of
insn-recog.cc and patched the offending part with logic from a stage-2
insn-recog.cc I managed to previously capture:
```
--- insn-recog.cc.orig 2024-01-07 04:46:19.328295337 +0100
+++ insn-recog.cc 2024-01-07 04:41:52.025630846 +0100
@@ -41675,11 +41675,12 @@
break;
}
operands[0] = x3;
- if (!gpc_reg_operand (operands[0], E_SImode)
+ if (GET_CODE (x2) != MEM
|| GET_MODE (x2) != E_SImode)
return -1;
x4 = XEXP (x2, 0);
- if (GET_MODE (x4) != E_SImode)
+ if (GET_CODE (x4) != PLUS
+ || GET_MODE (x4) != E_SImode)
return -1;
switch (GET_CODE (x2))
{
```
This allowed all 3 stages to finish building. It results in lots of failed
comparisons for stage2 and stage3 files though, and is obviously not a workable
solution.
[Bug bootstrap/113174] gcc fails to bootstrap on ppc64le with clang-based host environment (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113174 --- Comment #9 from q66 --- tested with clang 18.x build and tip-of-tree 14.1 branch, still applies
