r290539 - [inline-asm]No error for conflict between inputs\outputs and clobber list

[Dimitry Andric via cfe-commits]

On 26 Dec 2016, at 13:23, Marina Yatsina via cfe-commits <cfe-commits at lists.llvm.org> wrote:
> 
> Author: myatsina
> Date: Mon Dec 26 06:23:42 2016
> New Revision: 290539
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=290539&view=rev
> Log:
> [inline-asm]No error for conflict between inputs\outputs and clobber list
> 
> According to extended asm syntax, a case where the clobber list includes a variable from the inputs or outputs should be an error - conflict.
> for example:
> 
> const long double a = 0.0;
> int main()
> {
> 
> char b;
> double t1 = a;
> __asm__ ("fucompp": "=a" (b) : "u" (t1), "t" (t1) : "cc", "st", "st(1)");
> 
> return 0;
> }
> 
> This should conflict with the output - t1 which is st, and st which is st aswell.

In FreeBSD ports, we are now getting this new error message when compiling svgalib (see https://bugs.freebsd.org/216154), when compiling with clang 4.0.0.

While fixing it, we noticed something strange (or interesting, depending on your point of view), namely that it does not seem to handle the first input or output operand, e.g. "0".  For example, svgalib has this inline function:

/* Always 32-bit align destination, even for a small number of bytes. */
static inline void *
 __memcpy_aligndest(void *dest, const void *src, int n)
{
    __asm__ __volatile__("cmpl $3, %%ecx\n\t"
                         "ja 1f\n\t"
                         "call * __memcpy_jumptable (, %%ecx, 4)\n\t"
                         "jmp 2f\n\t"
                         "1:call __memcpyasm_regargs\n\t"
                         "2:":
                         :"S"(dest), "d"(src), "c"(n)
                         :"ax", "0", "1", "2");
    return dest;
}

The error produced for this is:

svgalib-1.4.3/gl/inlstring.h:281:17: error: asm-specifier for input or output variable conflicts with asm clobber list
                         :"ax", "0", "1", "2");
                                     ^

And indeed, removing the "1" and "2" input operands fixes the error.  However, by definition, "0" is always an input or output operand, so should it not produce an error too?

-Dimitry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20170131/93d09a16/attachment.sig>