Issues with inline assembly

Hi guys,

I am trying to compile some files using clang + llvm and I am
encountering the following error during the linking step:

<inline asm>:1:2: error: ambiguous instructions require an explicit
suffix (could be 'btsw', 'btsl', or 'btsq')
        bts $14,(%eax)

Which basically does not make any sense, because I don't have the
mentioned inline assembly in any of the C files, and furthermore even
if I did, that is completely valid inline assembly (BTS as per x86
assembly reference does not need w,l or q modifiers)

N.B.:

The command that triggers the error is something along the lines of:
ld.gold -plugin LLVMgold.so -m elf_i386 -r -o final.o part1.o part2.o

@char:~/workspace$ clang -v
clang version 3.3.1
Target: x86_64-unknown-linux-gnu
Thread model: posix

@char:~/workspace$ ld.gold -v
GNU gold (Linux/GNU Binutils 2.24.51.0.1.20131106) 1.11

This has come up before <https://groups.google.com/forum/#!topic/llvm-dev/vomnIQjefzA>. I don't recall if there was a resolution.

Thanks for the link, completely missed when googled the issue. I think
no consensus was reached (I cannot find any commit in the repository
addressing such issues). I will try and search for the culprit of the
inline assembly and replace it with btsl.

As for the issue at hand, although after carefully reading both the
thread and re-reading the sections from the instructions set reference
it is a rather unpleasant behavior, the error thrown by the toolchain.
Since Intel is nowadays by far the biggest vendor for x86/x86_64
hardware and they do not mention a single thing about the existence of
suffixes for this instruction, it could be accommodated (maybe with a
warning though) and take the second option from the 3 you provided.

P.S. : after searching a bit more, it seems that llvm is in fact the
only toolchain that rejects/complains about the bts ambiguity, or at
least people using llvm get annoyed more easily and start spamming
mailing lists :).

This has come up before <https://groups.google.com/forum/#!topic/llvm-dev/vomnIQjefzA>. I don't recall if there was a resolution.

Thanks for the link, completely missed when googled the issue. I think
no consensus was reached (I cannot find any commit in the repository
addressing such issues). I will try and search for the culprit of the
inline assembly and replace it with btsl.

As for the issue at hand, although after carefully reading both the
thread and re-reading the sections from the instructions set reference
it is a rather unpleasant behavior, the error thrown by the toolchain.
Since Intel is nowadays by far the biggest vendor for x86/x86_64
hardware and they do not mention a single thing about the existence of
suffixes for this instruction, it could be accommodated (maybe with a
warning though) and take the second option from the 3 you provided.

One thing to note is that Intel syntax doesn't use suffixes for most (all?) instructions whereas AT&T syntax does. (Although, as I recall, no one actually found an authoritative description of AT&T syntax.) Thus it makes sense that Intel would say nothing about it.

P.S. : after searching a bit more, it seems that llvm is in fact the
only toolchain that rejects/complains about the bts ambiguity, or at
least people using llvm get annoyed more easily and start spamming
mailing lists :).

Certainly possible!

This has come up before <https://groups.google.com/forum/#!topic/llvm-dev/vomnIQjefzA>. I don’t recall if there was a resolution.

Thanks for the link, completely missed when googled the issue. I think
no consensus was reached (I cannot find any commit in the repository
addressing such issues). I will try and search for the culprit of the
inline assembly and replace it with btsl.

As for the issue at hand, although after carefully reading both the
thread and re-reading the sections from the instructions set reference
it is a rather unpleasant behavior, the error thrown by the toolchain.
Since Intel is nowadays by far the biggest vendor for x86/x86_64
hardware and they do not mention a single thing about the existence of
suffixes for this instruction, it could be accommodated (maybe with a
warning though) and take the second option from the 3 you provided.

One thing to note is that Intel syntax doesn’t use suffixes for most (all?) instructions whereas AT&T syntax does. (Although, as I recall, no one actually found an authoritative description of AT&T syntax.) Thus it makes sense that Intel would say nothing about it.

Yup.

There’s not a strong philosophical objection or anything like that to adding aliases for them. As the previous thread indicates, there’s subtleties involved, so it’s important that patches doing something about it are well documented about what they do, don’t do, and why. With that caveat, patches for fixing this would be very welcome.

P.S. : after searching a bit more, it seems that llvm is in fact the
only toolchain that rejects/complains about the bts ambiguity, or at
least people using llvm get annoyed more easily and start spamming
mailing lists :).

Certainly possible!

If the people using llvm are similar to the people developing it, it’s downright likely! :slight_smile:

There’s not a strong philosophical objection or anything like that to adding
aliases for them. As the previous thread indicates, there’s subtleties
involved, so it’s important that patches doing something about it are well
documented about what they do, don’t do, and why. With that caveat, patches
for fixing this would be very welcome.

I think it (well, a dodgy set of limits & semantics, but probably best
not to rehash that) actually happened after that last thread. At
least, my trunk now accepts the syntax mentioned by Razvan.

Cheers.

Tim.