[Bug target/108240] [13 Regression] ICE in emit_library_call_value_1 at gcc/calls.cc:4181 since r13-4894-gacc727cf02a144
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108240 --- Comment #9 from Kewen Lin --- I filed one new bug PR108415 for the ICE itself to avoid the confusion here. This ICE is not a regression, it's a latent bug, because: 1) Without the culprit commit r13-4894 (like using r13-4893 or reverting it), if we specify one more explicit option -m64, we can see the exactly same ICE. It's just concealed as we emit error first on Linux without -m64. (r13-4894 changed it not to emit error any more so no error to conceal then). 2) It's even nothing to do with powerpc64 handling, this ICE can be produced on ppc64 Linux with options "-m32 -mcpu=401 -mmodulo", so it's not 64 bit specific (so not powerpc64 handling related either). I put one comment about root cause of this ICE in PR108415.
[Bug target/108240] [13 Regression] ICE in emit_library_call_value_1 at gcc/calls.cc:4181 since r13-4894-gacc727cf02a144
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108240 --- Comment #8 from Kewen Lin --- (In reply to Segher Boessenkool from comment #7) > -m64 requires 64-bit instructions. We will ICE if we try to generate code > for -m64 without support for 64-bit insns enabled in the compiler. For > example, the stdu insn is required to implement the ABI sanely. > The current behavior for one explicit command line option -m64 doesn't violate the comment, the explicitly given -m64 will enable powerpc64 all the time, it makes -m64 compilation always have 64-bit insns enabled. It's the same for both cases before and after r13-4894. > If the user said they want a -mcpu= for a CPU that has no 64-bit insns, > but also wants to use -m64, we should just say sorry, that won't fly. I agree that this is a sensible thing to look into and make. But to change the behavior like this fully (on Linux, aix and darwin, 64 bit env w/ or w/o explicit -m64) is a big adjustment comparing with the previous behaviors. Since for the case that "the explicit option -m64 + cpu without 64-bit insn + Linux/aix/darwin" it doesn't emit errors before, for the cases that "no explicit option -m64 + cpu without 64-bit insn + aix/darwin" it only emits warnings before. Only for the case "no explicit option -m64 + cpu without 64-bit insn + Linux", it emits error before r13-4894. After the culprit commit it changes to not emit errors, this part is a regression, the proposed patch can fix it. But for the others in which cases we don't emit error before (for both cases before and after r13-4894), to make them to emit errors is new behavior, it could cost non-trivial efforts (at least on testing and some fixing on possible fallouts).
[Bug target/108240] [13 Regression] ICE in emit_library_call_value_1 at gcc/calls.cc:4181 since r13-4894-gacc727cf02a144
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108240 --- Comment #7 from Segher Boessenkool --- -m64 requires 64-bit instructions. We will ICE if we try to generate code for -m64 without support for 64-bit insns enabled in the compiler. For example, the stdu insn is required to implement the ABI sanely. If the user said they want a -mcpu= for a CPU that has no 64-bit insns, but also wants to use -m64, we should just say sorry, that won't fly.
[Bug target/108240] [13 Regression] ICE in emit_library_call_value_1 at gcc/calls.cc:4181 since r13-4894-gacc727cf02a144
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108240 --- Comment #6 from Kewen Lin --- (In reply to Kewen Lin from comment #5) > (In reply to Segher Boessenkool from comment #4) > > (In reply to Kewen Lin from comment #3) > > > With the culprit commit r13-4894, we always implicitly enable powerpc64 > > > for > > > both explicit and implicit 64 bit, it's the same as before for the > > > explicit > > > 64 bit case, but for the implicit 64 bit case, there is no chance for the > > > used cpu to unset powerpc64 (like this case). To keep it consistent with > > > the > > > previous, the fix can be to only enable powerpc64 implicitly for explicit > > > 64 > > > bit, while let it be for implicit 64 bit. > > > > No? If the user says to use a CPU without 64-bit instructions, while the > > user also says we require 64-bit insns (via -m64), we should just error. > > But both the previous behavior (before r13-4894) and the current behavior > (starting from r13-4894) honour the given explicit -m64, it would always > enable -mpowerpc64 at the same time without any errors/warnings. > It's implied that when the user explicitly specify -m64, the handlings would neglect the impact of CPU, I'm not sure if it's intentional but the reason probably is that the underlying CPU is actually 64 bit in most cases, so make -m64 win and the compilation can go forward. If we change the behavior to error for both explicit and implicit 64 bit, some compilations which worked in the past can start to fail (though it's arguable that it's expected). Note that for implicit 64 bit and no powerpc64, we gets errors on Linux but just warnings on darwin/aix (maybe more fallouts come out on them). So considering the current release phase, I'm inclined to just make it consistent with the previous, and try to adjust the behavior (as Segher's proposal) in next release.
[Bug target/108240] [13 Regression] ICE in emit_library_call_value_1 at gcc/calls.cc:4181 since r13-4894-gacc727cf02a144
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108240 --- Comment #5 from Kewen Lin --- (In reply to Segher Boessenkool from comment #4) > (In reply to Kewen Lin from comment #3) > > With the culprit commit r13-4894, we always implicitly enable powerpc64 for > > both explicit and implicit 64 bit, it's the same as before for the explicit > > 64 bit case, but for the implicit 64 bit case, there is no chance for the > > used cpu to unset powerpc64 (like this case). To keep it consistent with the > > previous, the fix can be to only enable powerpc64 implicitly for explicit 64 > > bit, while let it be for implicit 64 bit. > > No? If the user says to use a CPU without 64-bit instructions, while the > user also says we require 64-bit insns (via -m64), we should just error. But both the previous behavior (before r13-4894) and the current behavior (starting from r13-4894) honour the given explicit -m64, it would always enable -mpowerpc64 at the same time without any errors/warnings. > Not hide the problem (and cause many more problems!) > The behavior change is for the case without any explicit -m64 but the TARGET_DEFAULT has 64 bit set (implicit -m64). And yes, different from the previous behavior, the current behavior hides the error/warning and force the -mpower64, so I posted one patch at: https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609492.html It would allow that powerpc64 gets unset if the user says to use a CPU without 64-bit instructions and with implicit 64 bit.
[Bug target/108240] [13 Regression] ICE in emit_library_call_value_1 at gcc/calls.cc:4181 since r13-4894-gacc727cf02a144
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108240 --- Comment #4 from Segher Boessenkool --- (In reply to Kewen Lin from comment #3) > With the culprit commit r13-4894, we always implicitly enable powerpc64 for > both explicit and implicit 64 bit, it's the same as before for the explicit > 64 bit case, but for the implicit 64 bit case, there is no chance for the > used cpu to unset powerpc64 (like this case). To keep it consistent with the > previous, the fix can be to only enable powerpc64 implicitly for explicit 64 > bit, while let it be for implicit 64 bit. No? If the user says to use a CPU without 64-bit instructions, while the user also says we require 64-bit insns (via -m64), we should just error. Not hide the problem (and cause many more problems!) We used to do that: f951: Error: ‘-m64’ requires a PowerPC64 cpu We can do such a check again, just in a bit different spot probably.
[Bug target/108240] [13 Regression] ICE in emit_library_call_value_1 at gcc/calls.cc:4181 since r13-4894-gacc727cf02a144
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108240 Richard Biener changed: What|Removed |Added Summary|ICE in |[13 Regression] ICE in |emit_library_call_value_1 |emit_library_call_value_1 |at gcc/calls.cc:4181 since |at gcc/calls.cc:4181 since |r13-4894-gacc727cf02a144|r13-4894-gacc727cf02a144 Priority|P3 |P1
