similar to: [LLVMdev] Issues with inline assembly

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

On Wed, Nov 20, 2013 at 8:55 PM, Stephen Checkoway <s at pahtak.org> wrote: > > 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

On Nov 20, 2013, at 4:11 PM, Ghitulete Razvan <razvan.ghitulete at gmail.com> wrote: > On Wed, Nov 20, 2013 at 8:55 PM, Stephen Checkoway <s at pahtak.org> wrote: >> >> 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

On Wed, Jul 10, 2013 at 7:15 PM, Jim Grosbach <grosbach at apple.com> wrote: > > 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

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

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

On Nov 20, 2013, at 1:26 PM, Stephen Checkoway <s at pahtak.org> wrote: > > On Nov 20, 2013, at 4:11 PM, Ghitulete Razvan <razvan.ghitulete at gmail.com> wrote: > >> On Wed, Nov 20, 2013 at 8:55 PM, Stephen Checkoway <s at pahtak.org> wrote: >>> >>> This has come up before <https://groups.google.com/forum/#!topic/llvm-dev/vomnIQjefzA>. I

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

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,

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.

Jim Grosbach wrote: > That does raise a clarifying question here. Is the code you’re interested in > using Intel or AT&T syntax? > > Also note that the question isn’t whether we should support the btr/bts > instructions. We absolutely must (and do). The question is whether we are > properly handling the un-suffixed mnemonic form of the assembly syntax. > > Perhaps you

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

Linus Torvalds wrote: >> btrl $1, 0 >> btr $1, 0 >> btsl $1, 0 >> bts $1, 0 > > What the heck is that supposed to show? I was trying to show a reduced case where gas doesn't complain, but llvm-mc does. Try compiling this with llvm-mc, and you'll get: .text btrl $1, 0 in.s:2:1: error: ambiguous instructions require an

Hi, The issue perhaps wasn't explained ideally (and possibly shouldn't have been CCed directly to you either, so apologies, but now that there *is* a discussion...) > Try some actual relevant test instead: > > bt %eax,mem > bt %rax,mem > > and notice how they are actually fundamentally different. Test-case: I'm coming at this from the compiler side, where the

(resent without HTML) On 07/14/2013 05:56 AM, Ramkumar Ramachandra 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 assembler will

Hello, I get this error when compiling this code with llvm-gcc: error: unsupported inline asm: input constraint with a matching output constraint of incompatible type! #include <stdio.h> #include <stdlib.h> #include <sys/time.h> #include <sys/types.h> #include <unistd.h> int main(void) {

Stephen Checkoway wrote: > [...] Thanks for the absolutely splendid analysis! > For the memory, immediate form without the suffix, it seems like the options are > 1. If the immediate value is in [0,15], use btsl/btrl since it saves a byte, otherwise error; > 2. Follow both gas's behavior and the Solaris assembler manual Jim Grosbach linked to which stated that unsuffixed

I'm new to asterisk and fror a cupple of days I heave been googleing the net for digium "clones", because it's very hard for me to get a digium card (X100P). Does anyone Know another substitute for X100P (I know that intel based modem with chip 537/MD3200 is working but I did not find any of those) ? I made it work with an Intel 536 (with a costumised driver that I found on