[cfe-dev] Where is the unknown token when using the Integrated Assembler (Intel syntax, neg instruction)?

[Reid Kleckner]

BTW, I filed a PR for this: https://llvm.org/bugs/show_bug.cgi?id=24232

I'm not interested in implementing ".intel_syntax prefix", but I am
interested in making this code parse.

On Sat, Jul 25, 2015 at 12:01 PM, Saleem Abdulrasool <compnerd at compnerd.org>
wrote:

> On Thu, Jul 23, 2015 at 11:15 AM, Reid Kleckner <rnk at google.com> wrote:
>
>> I think it's complaining about the % in %rcx. Intel assembly syntax
>> doesn't use the % prefix on registers.
>>
>
> It does, if you are using gas :-(.  ".intel_syntax prefix" will expect
> prefix'ed registers.  Unfortunately, we do not support this mode, only
> ".intel_syntax noprefix".
>
> I don't think our backend knows how to expand operands using anything
>> other than AT&T syntax. If this is the case, using .intel_syntax directives
>> in inline assembly won't work very well until something changes.
>>
>> If you need intel syntax, what you could try doing is passing
>> -fasm-blocks and writing MSVC / Intel style inline assembly, which looks
>> like:
>>
>> int SomeFunction(int* ptr, int val1, int val2) {
>>   __asm {
>>     neg val1
>>   };
>> }
>>
>> I would only recommend doing this if you already have ifdefs to support
>> inline asm in MSVC.
>>
>> On Wed, Jul 22, 2015 at 11:42 PM, Jeffrey Walton <noloader at gmail.com>
>> wrote:
>>
>>> I'm part of an existing project, and I'm working on support for
>>> Clang's Integrated Assembler. The project has copious amounts of
>>> inline assembly (both stand alone one-liners for shift and rotates;
>>> and blocks for things like AES and GCM mode). Even better (maybe
>>> worse?), it mixes AT&T and Intel because it supports Microsoft and GNU
>>> platforms.
>>>
>>> I'm having trouble understanding an error message from the assembler.
>>> The message is on the use of 'neg' under the Intel dialect:
>>>
>>> <inline asm>:3:7: note: instantiated into assembly here
>>>          neg %rcx;
>>>              ^
>>>
>>> The code looks like:
>>>
>>> int SomeFunction(int* ptr, int val1, int val2)
>>> {
>>>     int ret;
>>>     __asm__ __volatile (
>>>         ".intel_syntax" "\n"
>>>         neg %1;
>>>         ...
>>>     )
>>>
>>>    return ret;
>>> }
>>>
>>> I'm testing on x86_64, so I tried changing to 'negq %1;' with no joy.
>>> (Taking a hint from
>>> http://clang.llvm.org/compatibility.html#inline-asm
>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__clang.llvm.org_compatibility.html-23inline-2Dasm&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=CnzuN65ENJ1H9py9XLiRvC_UQz6u3oG6GUNn7_wosSM&m=iviteUf0h4DXGmyCwacxxX94il3QGLPa732kzx619gU&s=7BAGKVNNStBkRhrcBaSaTLG9SF7mLw5KbxsHwnGklhg&e=>
>>> ):
>>>
>>> <inline asm>:3:8: note: instantiated into assembly here
>>>          negq %rcx;
>>>              ^
>>>
>>> I'm experiencing it with both Apple's Clang 3.2, and LLVM's Clang
>>> 3.6.0 built from sources (http://llvm.org/releases/
>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_releases_&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=CnzuN65ENJ1H9py9XLiRvC_UQz6u3oG6GUNn7_wosSM&m=iviteUf0h4DXGmyCwacxxX94il3QGLPa732kzx619gU&s=5uzZEVAD8a1EU7oyzFOsKq35kSa0cZrHJsrsYm5vc0U&e=>
>>> ).
>>>
>>> Naively (and I stress naively), “unknown token in expression” appears
>>> to be a bogus message since the assembly instruction its complaining
>>> about does not seem to have a problem. So I suspect there is something
>>> else the integrated assembler finds offensive.
>>>
>>> Could anyone help me understand what the issue is?
>>>
>>> Thanks in advance. Jeff.
>>>
>>> _______________________________________________
>>> cfe-dev mailing list
>>> cfe-dev at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>>
>>
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>
>>
>
>
> --
> Saleem Abdulrasool
> compnerd (at) compnerd (dot) org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150727/be6f51ad/attachment.html>