[Bug inline-asm/65897] GAS(asm) "named variable" of extended asm (type ::"m" or "g") generated in wrong code style, variable stays still in ".att_syntax" -32(%ebp) not ".intel_syntax noprefix" DWORD PTR [ebp-0x20] while rest of the code is switched on correctly to Intel.

["sstsoft at wp dot pl" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65897

stanley <sstsoft at wp dot pl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |---

--- Comment #2 from stanley <sstsoft at wp dot pl> ---
#include <iostream>
using namespace std;
int i asm("i");
int main() {    
i = 0;
        cout << "!!!Hello World!!!" << endl; // prints !!!Hello World!!!
        cout << "i=" << i << endl;
        asm(".intel_syntax noprefix\n mov eax,13\n mov [i],eax\n");
        cout << "i=" << i << endl;

        i = 0;
        cout << "i=" << i << endl;
        asm(".intel_syntax noprefix\n mov eax,14\n mov %[named_var],eax\n" :
[named_var] "=g" (i));
        cout << "i=" << i << endl;
        return 0;
}

Gives output like this:
"!!!Hello World!!!
i=0
i=13
i=0
i=14"

1. I have checked LLVM/Clang + Eclipse CDC. 
It can do this ^^ trick without a single problem(.att_syntax switched globally
but it compiles as a charm) It's only possible with Clang(compatible with GAS),
and I don't even need to end asm() block switched to correct ".att_syntax". 
With GCC compiler if I don't do this, the linker would be confused for first
line of code after my asm(".intel") block (wrong syntax of gcc "product"). As
You mentioned GCC is blind to local switches into asm block. Why? Because it's
his nature ofc :)

2. Simple "mov i,eax" wouldn't work with gcc/gas, neither "mov [i],eax", "mov
DWORD PTR[i],eax" because gcc ignores [] and it doesn't matter in the output.
This is different than written in manual - for me it's a bug. But..
since I know "i" it's address located in ds:blabla and gcc delete all of [] if
I want to access "i" I should "mov edi,i" then "mov [edi],eax" or something
like that. Again..GCC is not buggy? Huh? :)
For references or pointers it's the same so it's very confusing. GAS doesn't
recognizes "&" "*". The only way to force is named variable but as I mentioned
in previous comment - it doesn't working properly.

3. Indexes also not working[1] properly for pointers. If i pass:
char  bla[10]; //and then 
char *bla_ptr = (char*)&bla; //and then, into asm "mov bla_ptr[2],al" it
wouldn't copy al into 3rd byte of bla?! but into 3rd hihgest byte(little
indian) of bla_ptr val. After that it wouldnt be correct pointer anymore
(pointing somewhere but not there). It could be very confuseing. Rather than
everytime copy variables into some register and then [edi],eax global named
variables would be the best way.. but not working correctly in .intel_syntax  

4. The only way to do write into "i" without named variables in extended asm
inline is copy it's adress into register eq. mov edi,i; then mov [edi],somedata
When i switch -masm=intel it could be okey but... what if i want to compile
someone else code + my code in same project? But with different syntaxes?
Those guys know's how GCC works so they wrote .att_syntax or end their asm's.
Then.. linker is confused again but now with intel syntaxed gcc output rather
than .att :)

But, Andrew said - it's not a bug, it's a? Feature?
I know global variables are bad, very bad especially in multi-threaded program,
i know why ;) I know the __bulitin, i know .s "offline" assembly. I know it
would be easier to access and manipulate some local "i" by simple define it as
"int i asm("eax");" or :  "=r" (i) : "eax") and just manipulate them without
wasteing processor time(accessing memmory) and wasteing stack space for
storeing it. But hey... instead of helping GCC  compicates it :)
For ATT syntax everything(almost) works as it should but hey.. why bother
people for intel if it's not working correctly! 

END. Clang follows "local" asm() switches and gives correct .s output for it's
own compiled C code after them. It now suport for Microsoft asm{} - smart
enought to discover what registers dev use. Smart enought to move data into
memory adress not complain. Linker is not confused when i compile units from
other developers whose wrote them for GCC without -masm=intel so end's up with
.att_syntax by default. They could end up whatever they like. I could do
whatever i like - what should be as much intuitive as it could in SSE,AVX era
when good C code is not enought. 

In GCC this is very serious problem, gcc stuck in 70's .ATT era
If gas have "no way" it shouldn't support for "g" "m" type variables then! Or
someone should make them see each other. Lack of GAS - GCC communication
whatever... this is not in my worries list, but on gcc commiters. Maybe someone
should open way for it!? 
huh? Andrew?