>>> On 10.04.18 at 08:42, <ja...@redhat.com> wrote:
> On Mon, Apr 09, 2018 at 11:50:14PM -0600, Jan Beulich wrote:
>> >> As ICC generates the same assembly on the instructions:
>> >>         mov     eax, DWORD PTR k1[rip]
>> >> ...
>> >>         mov     eax, DWORD PTR xmm0[rip]
>> >> I think either the intel syntax spec is faulty, or gas is buggy and should
>> >> figure out that after *WORD PTR and before [ there is symbol rather than
>> >> register name.  Some testcases e.g. have k1 as function name and that
>> >> results in other asm errors (about .size directive).
>> >
>> >How does Intel syntax support symbols like eax, k1 and xmm0 with
>> >".intel_syntax noprefix"?
>> I've noticed this problem about two weeks ago as well, and have a patch
>> mostly ready (but need to get around to both produce a proper testcase
>> and regression test the whole thing); that won't be until in a couple of
>> weeks time, though - if you think this is needed earlier, I can hand you
>> the fragments I have. As an aside - you realize this isn't an Intel syntax
>> only issue, as "noprefix" can as well be specified with .att_syntax.
>> I should note though that the fix won't go as far a Jakub suggests: Context
>> doesn't matter for recognizing whether a symbol is a register. For something
>> like the above to compile, .arch would need to be used to disable the
>> respective register groups (e.g. .arch .noavx512f to make k1 an ordinary
>> symbol).
> That means there are still lots of valid programs that will never compile
> with the noprefix syntax, because you really can't disable those register
> groups when you need them.  Consider
> int eax;
> int foo (void) { return eax; }
> int ebx (void) { return 23; }
> /tmp/ccJBZxhZ.s: Assembler messages:
> /tmp/ccJBZxhZ.s:15: Error: invalid use of register
> /tmp/ccJBZxhZ.s: Error: .size expression for ebx does not evaluate to a 
> constant
> Line 15 is:
>         mov     eax, DWORD PTR eax[rip]
> and the .size expression is:
>         .size   ebx, .-ebx

All true, yet that's the way MASM works, and that's the ultimate
reference for Intel syntax. I believe that's also (part of) the reason
why in the DOS/Windows world C-level symbols have always been
prefixed by an underscore at the assembly / object file level.

> And no, this isn't artificial, it appears e.g. quite a lot in GCC testsuite.
> So, what should the compiler do if it detects such identifiers in an
> instruction?  Temporarily do .intel_syntax prefix and prefix all the
> registers, then revert?

That's one option, but I'm unconvinced of this being a workable
one, especially considering asm() uses where the programmer
would make the assumption of "norprefix" being in effect. The
question is what use "noprefix" is in a world where language level
symbols can conflict with assembler level reserved names.


Reply via email to