https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97708
--- Comment #30 from Alexander Monakov ---
Asm operand binding should work by looking at bound lvalue: "c"(a) binds an
lvalue so if 'a' is a register var the compiler must remember its associated
register; "c"(a+0) binds an rvalue, so what kind
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97708
--- Comment #29 from Segher Boessenkool ---
(In reply to Richard Biener from comment #26)
> So it would need to be diagnosed in the FE (only), making a + 0 valid and
> a not. Eh.
We do not *have* to diagnose anything, certainly not things that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97708
--- Comment #28 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #25)
> Even if we wanted to do something about it (which I disagree with, e.g.
> given that the implementation matches the documentation), you run into the
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97708
--- Comment #27 from Segher Boessenkool ---
(In reply to Alexander Monakov from comment #24)
> Segher, did you really mean to mark the bug resolved/fixed?
No, if I did that, I have no idea how :-)
> Given that the only supported use of local
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97708
Richard Biener changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97708
--- Comment #25 from Jakub Jelinek ---
Even if we wanted to do something about it (which I disagree with, e.g. given
that the implementation matches the documentation), you run into the problem
that even GIMPLE nor RTL differentiates between:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97708
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97708
Segher Boessenkool changed:
What|Removed |Added
Resolution|INVALID |FIXED
--- Comment #23 from Segher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97708
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |INVALID
Status|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97708
--- Comment #21 from Segher Boessenkool ---
register float foo asm ("xmm0") = 0.99f;
asm volatile("movl %0, %%r8d\n\t"
"vmcall\n\t"
:: "g" (foo));
The user said operands[0] should go
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97708
--- Comment #20 from Jakub Jelinek ---
But the user didn't do anything wrong, perhaps just had bad expectations.
The user asked put the value of this variable into a general purpose register
or memory. So the compiler did that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97708
--- Comment #19 from Segher Boessenkool ---
Documenting that GCC behaves differently is just documenting a bug :-(
It should not be hard to detect this and give an error somewhere?
Saying "the user did something wrong" is true of course, but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97708
--- Comment #18 from Boris ---
It would be awesome if this text continued:
"... and specify any constraint letter that matches the register. If the
operand constraint doesn't match the register, former has higher priority over
the local
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97708
--- Comment #17 from Jakub Jelinek ---
It is all documented exactly in the place you've linked:
Then use the local variable for the asm operand and specify any constraint
letter that matches the register
^
The g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97708
--- Comment #16 from Boris ---
(In reply to Jakub Jelinek from comment #14)
> No, why? You ask it to go into a general register, so it goes there. The
> local register variable has no priority at all.
And where in the documentation does it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97708
--- Comment #15 from Jakub Jelinek ---
It is exactly the same as if you have some variable that must live in memory
(e.g. address taken), if you use a constraint that allows memory, it will be
put there without reloading, if it does not, then
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97708
--- Comment #14 from Jakub Jelinek ---
No, why? You ask it to go into a general register, so it goes there. The
local register variable has no priority at all. All it says the variable lives
in a particular register. If the constraints allow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97708
--- Comment #13 from Boris ---
Then you'd need to add a sentence saying that the register asm() specification
has lower prio and thus overridden by the input operand constraint. Which is
what we have here. And then refer to the text Segher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97708
--- Comment #12 from Jakub Jelinek ---
Definitely not. Because then it wouldn't describe what it actually does.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97708
--- Comment #11 from Boris ---
Drop "general":
"‘g’ Any register, memory or immediate integer operand is allowed."
because, as you guys say, it would stick it anywhere.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97708
--- Comment #10 from Jakub Jelinek ---
(In reply to Richard Biener from comment #9)
> I'm not a native speaker but maybe
>
> "'g' The compiler can choose any register, memory or immediate integer
> operand
> to put the value, except for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97708
Richard Biener changed:
What|Removed |Added
Keywords||documentation
--- Comment #9 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97708
--- Comment #8 from Jakub Jelinek ---
That is how GCC deals with all reloading, so I don't understand what is
surprising about it.
If you ask for something to be in register (or register class) xyz and it isn't
there, it is copied there.
Look at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97708
--- Comment #7 from Boris ---
(In reply to Jakub Jelinek from comment #6)
> I agree with Andrew here, the compiler does what it is asked to do, so puts
> the value into either memory or general purpose register. Neither "r" nor
> "g" allows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97708
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97708
Segher Boessenkool changed:
What|Removed |Added
Resolution|INVALID |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97708
Andrew Pinski changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97708
Segher Boessenkool changed:
What|Removed |Added
Resolution|INVALID |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97708
--- Comment #2 from Boris ---
(In reply to Andrew Pinski from comment #1)
> "g" constraint won't work here:
So in that case gcc should fail the build. Which it does not.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97708
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
30 matches
Mail list logo
