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