https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
--- Comment #10 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to Rich Felker from comment #8)
> > Then LLVM has more to fix. Constraints never look at types. A register
> > constraint (like "wa") simply says what registers are valid.
>
> This is blatently false. For x86:
>
> int foo(int x)
> {
> __asm__("" : "+f"(x));
> return x;
> }
>
> yields "error: inconsistent operand constraints in an 'asm'".
That does not look at types. It complains that "x" lives in memory,
while the constraint requires a register (a floating point register).
There are three different places a datum can live: in a register, in
memory, or in a constant. "r", "m", and "i" as constraints, very
roughly. PowerPC has *no* instructions that accept more than one of
these three (you can still have it in uncommon assembler code that
does not generate machine insns -- as a simple dumb example, in a
comment for example, like asm("# %0" :: "g"(some_var));
("g" means "rmi" essentially).
And "types" are not the same as "modes". This is another common
misunderstanding.
> > For many w* using it in inline asm is plain wrong; for the rest of the
> > register constraints it is useless, plain "wa" should be used; and there
> > are some special ones that are so far GCC implementation detail that you
> > probably wouldn't even consider using them.
>
> The asm register constraints are a public interface of "GNU C" for the
> particular target architecture.
No, they are not. The constraints are an implementation detail. And
they *have* to be, or we could never again improve anything.
Unfortunately we currently document most of them in the user manual as
well. It's on my list of things to change, for GCC 10. Most targets
still have this problem, fwiw.
> Randomly removing them is a breaking change
> in the language. There is no documented or even reliable way to detect which
> ones work correctly for a particular compiler version, so change or removal
> of semantics is particularly problematic.
Yes. Use the common ones only.
> > The maintenance cost for all the constraints we keep around because some
> > important projects used them is considerable, fwiw.
>
> One line in a table to preserve stability of the language is not what I call
> "maintenance cost".
That is the other side of it: yes, we should give people more guidance
what they should (and shouldn't!) do in inline asm.
What I am talking about is that people rely on implementation details
no matter what we do, and then prevent us from changing them.
