[Bug inline-asm/65897] New: GAS named variable of extended asm (::"m" or "g") is 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 corectly

[Bug inline-asm/65897] New: GAS named variable of extended asm (::"m" or "g") is 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 corectly

[sstsoft at wp dot pl]

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

            Bug ID: 65897
           Summary: GAS named variable of extended asm (::"m" or "g") is
                    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 corectly
           Product: gcc
           Version: 4.8.1
            Status: UNCONFIRMED
          Severity: blocker
          Priority: P3
         Component: inline-asm
          Assignee: unassigned at gcc dot gnu.org
          Reporter: sstsoft at wp dot pl
  Target Milestone: ---

GNU Asembler version 2.32.2
GCC 4.8.1
QT Creator 5.3.1

"g++ -c -fno-keep-inline-dllexport -save-temps -Wattributes
-fno-strict-aliasing -fwrapv -fno-aggressive-loop-optimizations -v
-momit-leaf-frame-pointer -os -Wno-write-strings -Wno-unused-variable
-Wno-unused-parameter -Wno-unused-label -Wno-unused-value -Wunknown-pragmas
-std=gnu++0x -pthread -fopenmp -fverbose-asm -g -std=c++0x -frtti -Wall -Wextra
-fexceptions -mthreads -DUNICODE -DQT_QML_DEBUG -DQT_DECLARATIVE_DEBUG
-DQT_GUI_LIB -DQT_CORE_LIB ..."

simple code as below:
int val;
asm volatile (".INTEL_SYNTAX noprefix\n mov eax,%[val]\n" :: [val] "g" [&val]
asm volatile (".ATT_SYNTAX\n");

is compiled into-> mov eax,-32(%ebp)

rather than correct version for Intel syntax:

-> mov eax,DWORD PTR[ebp-0x20]

First of all i thunk it was capital problem (INTEL not .intel) but it's not.
BTW. Why generated /APP /NO_APP rather than #APP #NO_APP? 
When i switch on -masm=intel globally and disable .intel_syntax in my inline
asm() it compiles whole code correctly(as above). 
When I make ATT code after asm(".att_syntax\n movl -32(%ebp),%eax\n" :: [val]
"g" (&val)); + .intel switched globaly ON, code generated for val stays in
"att" so, no error produced, compilation successed. It's happens either when
syntax is double changed into one asm() statement, 2 statements(as posted), or
three .intel + code + .att, Code .s for named variable is always formated wrong
(as default in ATT mode). Any other code even with global variables is produced
okey, asembler code is working but not when i add named variable (extended
assembly). Even if gcc optimizes val into registry, produces %eax rather than
eax output so it must be a bug not a feature.

I know there is =r, r mode. But for me it's bad that GCC don't know what
register names im using in inline asembly, GAS it's not. Named variables it's
only way to force asm for using locals, "g" mode, 
#__VA_ARGS__ myasm() = myasm_vars() defs is the only way for simpler ported
code. 

Bug is well known by others:
http://gotoanswer.com/?q=GCC+inline+assembly+error%3A+Error%3A+junk+%60%28%25esp%29%27+after+expression
https://www.c-plusplus.net/forum/106506-full
http://stackoverflow.com/questions/13856792/gcc-inline-assembly-error-error-junk-esp-after-expression

Sorry, english is not my primary language.

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

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
You changed the syntax but did not notify gcc. Gcc has no way of notifying of
the syntax change though. You can change it on the whole file though.

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

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?