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.
