[x86] Deferenced operands partially don't work in GCC inline assembly (with Intel syntax)

[TheComputerGuy96]

This is a documented GCC feature that partially doesn't work with Clang:
https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Output-Operands
https://www.felixcloutier.com/documents/gcc-asm.html#puts

Here's a Godbolt example of this behavior: https://godbolt.org/z/v7q7oso75 (as you can see GCC has no issues compiling and running the example while Clang doesn't even compile it)

Using a r constraint would work here (but that's still a difference in behavior)

[llvmbot]

@llvm/issue-subscribers-backend-x86

Author: Echo J. (TheComputerGuy96)

This is a documented GCC feature that partially doesn't work with Clang: https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Output-Operands https://www.felixcloutier.com/documents/gcc-asm.html#puts

Here's a Godbolt example of this behavior: https://godbolt.org/z/v7q7oso75 (as you can see GCC has no issues compiling and running the example while Clang doesn't even compile it)

Using a r constraint would work here (but that's still a difference in behavior)

[pinskia]

I think this is invalid.
The 'g' constraint from GCC documentation (https://gcc.gnu.org/onlinedocs/gcc/Simple-Constraints.html) says:

Any register, memory or immediate integer operand is allowed, except for registers that are not general registers.

So in this case GCC just happens to be using a register but LLVM chooses a memory operand. But are correct with respect to that constraint.

More over try compiling the GCC version at -O1+, you will see you are given the memory location of tadpole and then you get the "wrong" result (you get the address that is contained in tadpole rather than the value that is contained in the address that tadpole points to).

[TheComputerGuy96]

Maybe at least Clang should give better error messages for this case then?

I think I found an actual issue with call instruction and i operand but that will be for another issue