[Bug rtl-optimization/114664] -fno-omit-frame-pointer causes an ICE during the build of the greenlet package
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114664 --- Comment #16 from Segher Boessenkool --- Yup, GPR31 is used for the emulated frame pointer, so this is user error: saying a fixed-purpose register is clobbered makes no sense. You are not allowed to use any register that the compiler uses for function calling any other way. It is a bad idea to use -fno-omit-frame-pointer on Power, btw, just like on any other architecture that does not have a frame pointer architecturally. We don't have one in any ABI even (for C at least, who knows what other languages (or language implementations) do). It is a grudge for targets that do not generate proper DWARF, or you can use it to quickly validate some (suspected!) bug is not in certain parts of the compiler; but we do not want to ever use it by default, esp. because it is so costly. Benchmark it, and quickly be dissuaded from even thinking about ever doing this. Progress is Good.
[Bug rtl-optimization/114664] -fno-omit-frame-pointer causes an ICE during the build of the greenlet package
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114664 Peter Bergner changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #15 from Peter Bergner --- (In reply to Richard Sandiford from comment #14) > Yeah, I think so. Ok, then marking as INVALID and greenlet will need to come up with some other solution than the one they're using.
[Bug rtl-optimization/114664] -fno-omit-frame-pointer causes an ICE during the build of the greenlet package
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114664 --- Comment #14 from Richard Sandiford --- Yeah, I think so.
[Bug rtl-optimization/114664] -fno-omit-frame-pointer causes an ICE during the build of the greenlet package
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114664 --- Comment #13 from Peter Bergner --- So I think the conclusion is we should close this as INVALID, correct?
[Bug rtl-optimization/114664] -fno-omit-frame-pointer causes an ICE during the build of the greenlet package
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114664
--- Comment #12 from Richard Sandiford ---
(In reply to Peter Bergner from comment #11)
> > > but how are users supposed to know whether
> > > -fno-omit-frame-pointer is in effect or not? I've looked and there is no
> > > pre-defined macro a user could check.
> > That might be a useful thing to have, but if the programmer has no control
> > over the build flags (i.e. cannot require/force -fomit-frame-pointer) then I
> > think the asm has to take care to save and restore the frame pointer itself.
> >
> > Dropping "31" from the asm means that the asm must preserve the register.
> > Things will go badly if the asm doesn't do that.
>
> So r31 which we use as our frame-pointer reg is a non-volatile/callee saved
> register, so it must be saved, but I guess they (greenlet) cannot use the
> method of mentioning it in the asm clobber list to perform that.
I was thinking of just the asm in isolation, rather than its effect on the
containing function's callee-save set.
If you have:
asm volatile ("…");
then GCC expects r31 after the asm to equal r31 before the asm, regardless of
the -fomit-frame-pointer setting. If the asm is:
asm volatile ("li r31,0");
(sorry, I've forgotten the actual Power asm :)) then things will go wrong if
GCC tries to use r31 after the asm.
If the asm clobbers r31 then it must mention it in the clobber list. As things
stand, it's not possible to mention r31 in the clobber list if
-fno-omit-frame-pointer. This means that the only option for code that wants
to support -fno-omit-frame-pointer is to make the asm's contents preserve r31,
using an explicit save and restore if necessary.
And that kind-of makes sense. If an asm clobbers the frame pointer, that
removes GCC's main option for restoring data after the asm. A lot of other
clobbers would be handled by loading data relative to the frame pointer. If
the frame pointer itself has gone then things get tricky.
[Bug rtl-optimization/114664] -fno-omit-frame-pointer causes an ICE during the build of the greenlet package
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114664 --- Comment #11 from Peter Bergner --- (In reply to Richard Sandiford from comment #10) > Yeah, I agree it's an error. The PR says “ICE”, but is there an internal > error? The “cannot be used in ‘asm’ here” is a normal user-facing error, > albeit with bad error recovery, leading us to report the same thing multiple > times. My bad for calling it an ICE. Clearly it's not an ICE but a normal error as you say. > > but how are users supposed to know whether > > -fno-omit-frame-pointer is in effect or not? I've looked and there is no > > pre-defined macro a user could check. > That might be a useful thing to have, but if the programmer has no control > over the build flags (i.e. cannot require/force -fomit-frame-pointer) then I > think the asm has to take care to save and restore the frame pointer itself. > > Dropping "31" from the asm means that the asm must preserve the register. > Things will go badly if the asm doesn't do that. So r31 which we use as our frame-pointer reg is a non-volatile/callee saved register, so it must be saved, but I guess they (greenlet) cannot use the method of mentioning it in the asm clobber list to perform that.
[Bug rtl-optimization/114664] -fno-omit-frame-pointer causes an ICE during the build of the greenlet package
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114664 --- Comment #10 from Richard Sandiford --- (In reply to Peter Bergner from comment #7) > Then that would seem to indicate that mentioning the frame pointer reg in > the asm clobber list is an error Yeah, I agree it's an error. The PR says “ICE”, but is there an internal error? The “cannot be used in ‘asm’ here” is a normal user-facing error, albeit with bad error recovery, leading us to report the same thing multiple times. > but how are users supposed to know whether > -fno-omit-frame-pointer is in effect or not? I've looked and there is no > pre-defined macro a user could check. That might be a useful thing to have, but if the programmer has no control over the build flags (i.e. cannot require/force -fomit-frame-pointer) then I think the asm has to take care to save and restore the frame pointer itself. Dropping "31" from the asm means that the asm must preserve the register. Things will go badly if the asm doesn't do that.
[Bug rtl-optimization/114664] -fno-omit-frame-pointer causes an ICE during the build of the greenlet package
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114664 --- Comment #9 from Peter Bergner --- (In reply to Kewen Lin from comment #8) > I noticed even without -fno-omit-frame-pointer, the test case still fails > with the same symptom (with error msg rather than ICE), did I miss something? With no option, we default to -fomit-frame-pointer and that option does not guarantee we actually will omit the frame pointer.
[Bug rtl-optimization/114664] -fno-omit-frame-pointer causes an ICE during the build of the greenlet package
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114664 --- Comment #8 from Kewen Lin --- (In reply to Peter Bergner from comment #7) > (In reply to Andrew Pinski from comment #6) > > Pre-IRA fix was done to specifically reject this: > > https://inbox.sourceware.org/gcc-patches/ > > ab3a61990702021658w4dc049cap53de8010a7d86...@mail.gmail.com/ > > Then that would seem to indicate that mentioning the frame pointer reg in > the asm clobber list is an error, but how are users supposed to know whether > -fno-omit-frame-pointer is in effect or not? I've looked and there is no > pre-defined macro a user could check. I noticed even without -fno-omit-frame-pointer, the test case still fails with the same symptom (with error msg rather than ICE), did I miss something?
[Bug rtl-optimization/114664] -fno-omit-frame-pointer causes an ICE during the build of the greenlet package
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114664 --- Comment #7 from Peter Bergner --- (In reply to Andrew Pinski from comment #6) > Pre-IRA fix was done to specifically reject this: > https://inbox.sourceware.org/gcc-patches/ > ab3a61990702021658w4dc049cap53de8010a7d86...@mail.gmail.com/ Then that would seem to indicate that mentioning the frame pointer reg in the asm clobber list is an error, but how are users supposed to know whether -fno-omit-frame-pointer is in effect or not? I've looked and there is no pre-defined macro a user could check.
[Bug rtl-optimization/114664] -fno-omit-frame-pointer causes an ICE during the build of the greenlet package
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114664 --- Comment #6 from Andrew Pinski --- Pre-IRA fix was done to specifically reject this: https://inbox.sourceware.org/gcc-patches/ab3a61990702021658w4dc049cap53de8010a7d86...@mail.gmail.com/
[Bug rtl-optimization/114664] -fno-omit-frame-pointer causes an ICE during the build of the greenlet package
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114664 --- Comment #5 from Andrew Pinski --- I wonder why they are not using getcontext/savecontext/swapcontext instead ...
[Bug rtl-optimization/114664] -fno-omit-frame-pointer causes an ICE during the build of the greenlet package
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114664 --- Comment #4 from Peter Bergner --- (In reply to Andrew Pinski from comment #3) > Well I am going to say this about the code in that repo, the inline-asm in > slp_switch looks very broken anyways. 100% agree, but broken for other reasons. I think still TBD whether the minimal test case here is supposed to work or not.
[Bug rtl-optimization/114664] -fno-omit-frame-pointer causes an ICE during the build of the greenlet package
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114664 Peter Bergner changed: What|Removed |Added CC||doko at gcc dot gnu.org, ||law at gcc dot gnu.org, ||linkw at gcc dot gnu.org, ||meissner at gcc dot gnu.org, ||rsandifo at gcc dot gnu.org, ||segher at gcc dot gnu.org, ||vmakarov at gcc dot gnu.org Last reconfirmed||2024-04-09 Status|UNCONFIRMED |NEW Ever confirmed|0 |1
[Bug rtl-optimization/114664] -fno-omit-frame-pointer causes an ICE during the build of the greenlet package
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114664 --- Comment #3 from Andrew Pinski --- Well I am going to say this about the code in that repo, the inline-asm in slp_switch looks very broken anyways.
[Bug rtl-optimization/114664] -fno-omit-frame-pointer causes an ICE during the build of the greenlet package
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114664
--- Comment #2 from Peter Bergner ---
CC'ing some architecture and RA experts for their input.
I believe the riscv64 test showing the same issue would be:
void
bug (void)
{
__asm__ volatile ("" : : : "s0");
}
...but I don't have a cross compiler right now to verify.
Interestingly, I tried what I thought would be the aarch64 test case
(clobbering x29), but it did not ICE. Did I use the wrong hard frame pointer
register or is aarch64 doing something different here?
[Bug rtl-optimization/114664] -fno-omit-frame-pointer causes an ICE during the build of the greenlet package
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114664 --- Comment #1 from Andrew Pinski --- Let me find the dups ...
