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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114664
Peter Bergner changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114664
--- Comment #14 from Richard Sandiford ---
Yeah, I think so.
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?
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
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,
>
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
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
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/
> >
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/
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/
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 ...
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114664
Peter Bergner changed:
What|Removed |Added
CC||doko at gcc dot gnu.org,
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.
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114664
--- Comment #1 from Andrew Pinski ---
Let me find the dups ...
17 matches
Mail list logo
