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

Dimitry Andric via cfe-commits cfe-commits at lists.llvm.org
Tue Jan 31 12:39:06 PST 2017

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"
                         :"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?


-------------- 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>

More information about the cfe-commits mailing list