search for: btsw

...p, it’s the memory reference versions which IIUC require a suffix. > > I want to make sure we do the right thing here and know why we’re doing it > rather than just adding some aliases because it matches gas’ behavior. The reason it's the right thing to do is that the mem/imm forms of btsw and btsl have exactly the same semantics. -Eli

On Wednesday 10 July 2013 22:18:23 Jevin Sweval wrote: > http://www.cs.fsu.edu/~baker/devices/lxr/http/source/linux/arch/x86/include/ > asm/bitops.h#L68 > > Here is one example that I found. Are the inline assembly arguments > ambiguous in size? It would help us for sure to build the kernel and others. -- JS

On Jul 10, 2013, at 6:54 PM, Stephen Checkoway <s at pahtak.org> wrote: > On Jul 10, 2013, at 17:44, Jim Grosbach <grosbach at apple.com> wrote: >> The length specifier is, as I understand it, required when the instruction references memory but is optional (and inferred from the registers) for the register variants. >> >> The best reference I know of for the

Hi, I happened to notice that linux.git uses plenty of btr and bts instructions (not btrl, btrw, btsl, btsw). For examples, see arch/x86/include/asm/bitops.h. LLVM barfs on these due to ambiguity, while GNU as is fine with them. Surely, there must be architectures where the w/l variant is unavailable? LLVM must support those architectures, no? Thanks.

...ed, even if it violates some transcendental (but unimplemented) authoritative standard [1]. If other mainstream assemblers handle btr/bts differently, I would see a cause for worry; otherwise, no. Eli Friedman wrote: > The reason it's the right thing to do is that the mem/imm forms of > btsw and btsl have exactly the same semantics. Not sure I understand this. [1]: Especially considering that we can't seem to find one.

Eli Friedman wrote: > The reason it's the right thing to do is that the mem/imm forms of > btsw and btsl have exactly the same semantics. The Intel documentation implies that this is the case: > If the bit base operand specifies a memory location, it represents the address of the byte in memory that contains the bit base (bit 0 of the specified byte) of the bit string (see Figure 3-2). T...

On Wed, Jul 10, 2013 at 11:12 AM, Ramkumar Ramachandra <artagnon at gmail.com> wrote: > Hi, > > I happened to notice that linux.git uses plenty of btr and bts > instructions (not btrl, btrw, btsl, btsw). For examples, see > arch/x86/include/asm/bitops.h. LLVM barfs on these due to ambiguity, > while GNU as is fine with them. Surely, there must be architectures > where the w/l variant is unavailable? Both variants have existed since the Intel 386. That said, we should probably handle...

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

On Jul 10, 2013, at 2:30 PM, Eric Christopher <echristo at gmail.com> wrote: > On Wed, Jul 10, 2013 at 2:08 PM, Ramkumar Ramachandra > <artagnon at gmail.com> wrote: >> Jim Grosbach wrote: >>> To say that another way, is the assembler correctly diagnosing a previously >>> unnoticed problem in the project source code, or is the assembler not >>>

On Nov 20, 2013, at 10:04 AM, Ghitulete Razvan <razvan.ghitulete at gmail.com> wrote: > <inline asm>:1:2: error: ambiguous instructions require an explicit > suffix (could be 'btsw', 'btsl', or 'btsq') > bts $14,(%eax) This has come up before <https://groups.google.com/forum/#!topic/llvm-dev/vomnIQjefzA>. I don't recall if there was a resolution. -- Stephen Checkoway

...t: .text btrl $1, 0 in.s:2:1: error: ambiguous instructions require an explicit suffix (could be 'btrw', 'btrl', or 'btrq') btr $1, 0 ^ btsl $1, 0 in.s:4:1: error: ambiguous instructions require an explicit suffix (could be 'btsw', 'btsl', or 'btsq') bts $1, 0 ^ Obviously, I misunderstood something major and screwed up the commit message. > int main(int argc, char **argv) > { > asm("bt %1,%0":"=m" (**argv): "a" (argc)); > asm("bt %1,%0":"...

On Sun, Jul 14, 2013 at 5:56 AM, Ramkumar Ramachandra <artagnon at gmail.com> wrote: > 1c54d77 (x86: partial unification of asm-x86/bitops.h, 2008-01-30) > changed a bunch of btrl/btsl instructions to btr/bts, with the following > justification: > > The inline assembly for the bit operations has been changed to remove > explicit sizing hints on the instructions, so the

1c54d77 (x86: partial unification of asm-x86/bitops.h, 2008-01-30) changed a bunch of btrl/btsl instructions to btr/bts, with the following justification: The inline assembly for the bit operations has been changed to remove explicit sizing hints on the instructions, so the assembler will pick the appropriate instruction forms depending on the architecture and the context. Unfortunately,