[PATCH] [clang] add support for -W{no-,}inline-asm-syntax

[Richard Sandiford]

Joerg Sonnenberger <joerg at britannica.bec.de> writes:
> On Thu, Feb 20, 2014 at 12:23:45PM +0000, David Woodhouse wrote:
>> The semantic model I expect — admittedly for no better reason than it's
>> what GCC has always done — is that the *text* within an inline asm
>> statement is treated as opaque by the compiler.
>
> But it isn't. This is a very strong case of behavior you got away with
> due to deficits in the implementation.

I disagree.  As per the discussion on gcc@, this seems like a valid
use of inline asm to me.  The point has always been that the effect
of the asm at the language level should be described entirely by the
constraints.  The compiler must never try to exploit its knowledge
of the asm string in order to do something different.

To take a MIPS example, if you have:

  register void *tp asm ("$2");
  asm (".set push;.set mips64r2;rdhwr $2,$29;.set pop" : "=d" (tp));

then a compiler with an integrated assembler would be able to see
that RDHWR is being used specifically with $2, and would know that
RDHWR actually allows any GPR.  But it would be invalid to exploit
that knowledge and replace $2 with another register, because the asm
instruction above is often emulated by the kernel and (for speed
reasons) the kernel only deals specifically with those operands.

Or take the more common example:

  asm ("" ::: "memory");

You don't need an integrated assembler to work out that "" doesn't
assemble to very much.  But the compiler can't use that knowledge
to say that the asm doesn't in fact clobber memory, since the asm
is being used as a compile-time memory barrier.  The same goes for
specific-operand barriers like:

  asm ("" : "=m" (foo));

And it isn't that "" is a special case.  Any asm that says it clobbers
memory must be treated as clobbering memory, even if the asm instructions
obviously don't.

Given that the compiler can't exploit its knowledge the asm contents,
I don't think unparseable asm strings should be treated as an error,
even for targets where -integrated-as is a reasonable default.
A warning seems like the right fit.  Of course, -Werror is always
there for users that want it to be an upfront compiler error,
even for -S.

Thanks,
Richard