https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #37 from Peter Bergner ---
(In reply to Rich Felker from comment #30)
> The code has been working for the past 8 years with the "0"(r2) input
> constraint added, and would clearly be valid if r2 were pre-initialized with
> something.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #36 from Segher Boessenkool ---
The kernel jumps back to an instruction *before* the syscall?!?
(I do not want to know about that any more, then, I am sure :-) )
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #35 from Rich Felker ---
> Oh, your real code is different, and $10 doesn't work for that? I see.
No, the real code is exactly that. What you're missing is that the kernel,
entered through syscall, has a jump back to the addu after
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #34 from Segher Boessenkool ---
Oh, your real code is different, and $10 doesn't work for that? I see.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #33 from Rich Felker ---
> An asm clobber just means "may be an output", and no operand will be assigned
> a register mentioned in a clobber. There is no magic.
This, plus the compiler cannot assume the value in any of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #32 from Segher Boessenkool ---
===
#define SYSCALL_CLOBBERLIST \
"$1", "$3", "$11", "$12", "$13", \
"$14", "$15", "$24", "$25", "hi", "lo", "memory"
long syscall6(long n, long a, long b, long c, long d, long e, long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #31 from Segher Boessenkool ---
An asm clobber just means "may be an output", and no operand will be assigned
a register mentioned in a clobber. There is no magic.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #30 from Rich Felker ---
> You need to make $r10 not a clobber but an inout, of course. And not
That's not a correct constraint, because it's clobbered by the kernel between
the first syscall instruction's execution and the second
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #29 from Segher Boessenkool ---
(In reply to Rich Felker from comment #27)
> Also just realized:
>
> > Rich, forcing "n" to be in "$r10" seems to do the trick? Is that a
> > reasonable
> solution for you?
>
> It doesn't even
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #28 from Rich Felker ---
And it looks like I actually hit this exact bug back in 2012 but misattributed
it:
https://git.musl-libc.org/cgit/musl/commit/?id=4221f154ff29ab0d6be1e7beaa5ea2d1731bc58e
I assumed things went haywire from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #27 from Rich Felker ---
Also just realized:
> Rich, forcing "n" to be in "$r10" seems to do the trick? Is that a reasonable
solution for you?
It doesn't even work, because the syscall clobbers basically all call-clobbered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #26 from Rich Felker ---
Indeed, I just confirmed that binding the n input to a particular register
prevents the "i" part of the "ir" alternative from working.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #25 from Peter Bergner ---
(In reply to Segher Boessenkool from comment #23)
> Before RA we have asm inputs
> [
> (reg/v:SI 196 [ n ])
> (reg/v:SI 4 $4 [ r4 ])
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #24 from Rich Felker ---
The reasons I was hesitant to force n to a particular register through an extra
register __asm__ temp var was that I was unsure how it would interact with the
"i" constraint (maybe prevent it from being
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #23 from Segher Boessenkool ---
It is harder for us to track it in an older bug with many older patches
for it, including stuff that needed fixups later. And, the "correct"
older bug for it would not be this one, anyway!
Before RA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #22 from Rich Felker ---
What should I call the new bug? The description sounds the same as this one,
and it's fixed in gcc 9.x, just not earlier versions, so it seems to be the
same bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #21 from Alexander Monakov ---
> I could guess the compiler might ignore your inputs/outputs that you specify
> if you don't have any % usages for them.
Are you seriously suggesting that examples in the GCC manual are invalid and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #20 from Segher Boessenkool ---
Confirmed with various 7 and 8 (I don't have a mips 6 around).
Don't reopen this bug, it is not necessarily related. Instead, please
open a new PR. Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #19 from Rich Felker ---
> This looks like bad inline asm. You seem to be using $2, $8, $9 and $sp
> explicitly and not letting the compiler know you are using them.
$2, $8, and $9 are all explicitly outputs. All changes to $sp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #18 from Peter Bergner ---
(In reply to Rich Felker from comment #16)
> long syscall6(long n, long a, long b, long c, long d, long e, long f)
[snip]
> : "ir"(n), "r"(r4), "r"(r5), "r"(r6)
...and "n" is an argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #17 from Peter Bergner ---
(In reply to Rich Felker from comment #16)
> long syscall6(long n, long a, long b, long c, long d, long e, long f)
> {
> register long r4 __asm__("$4") = a;
> register long r5 __asm__("$5") = b;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #16 from Rich Felker ---
> I didn't say this very well... The only issue is using the same hard
> register for two different operands. You don't need to do this for
> syscalls (and you do not *need* that *ever*, of course).
I hit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #15 from Segher Boessenkool ---
(In reply to Rich Felker from comment #12)
> > You can work around it on older GCC by simply not using a register var
> > for more than one asm operand, I think?
>
> Nope. Making a syscall inherently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #14 from Alexander Monakov ---
Just to clarify, the two testcases added in the quoted commit don't try to
catch the issue discussed here: that the operand is passed in a wrong register.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #13 from Peter Bergner ---
(In reply to Rich Felker from comment #12)
> > You can work around it on older GCC by simply not using a register var
> > for more than one asm operand, I think?
>
> Nope. Making a syscall inherently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #12 from Rich Felker ---
> You can work around it on older GCC by simply not using a register var
> for more than one asm operand, I think?
Nope. Making a syscall inherently requires binding specific registers for all
of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #11 from Segher Boessenkool ---
(In reply to Rich Felker from comment #10)
> This is a rather huge bug to have been fixed silently. Could someone who
> knows the commit that fixed it and information on what versions are affected
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
Rich Felker changed:
What|Removed |Added
CC||bugdal at aerifal dot cx
--- Comment #10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
Kaz Kylheku changed:
What|Removed |Added
CC||kkylheku at gmail dot com
--- Comment #9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #8 from Peter Bergner ---
(In reply to Alexander Monakov from comment #6)
> Peter, can you please clarify, is this actually fixed (as in, one of your
> patches addressed this particular issue) or just happens to be not
> reproducible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #7 from Segher Boessenkool ---
Feel free to send a patch.
Yes it is fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #6 from Alexander Monakov ---
If this is fixed then the testcase should be added to the testsuite to make
sure we catch it if we regress again (this worked before e.g. on gcc-4.1).
Peter, can you please clarify, is this actually
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
Segher Boessenkool changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #4 from Peter Bergner ---
Ok, so we can mark this as already fixed then and leave it at that. That's
fine with me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #2 from Peter Bergner ---
None of my recent IRA or LRA patches were back ported and I wasn't planning on
it, given the fallout they caused. Do we know for sure this doesn't work on
GCC 8?
Given when Alexander opened this bug, I'm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
Segher Boessenkool changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org,
37 matches
Mail list logo
