This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug rtl-optimization/44288] [Extended inline asm] wrong assembly generation on IA32



------- Comment #6 from dg dot recrutement31 at gmail dot com  2010-05-27 11:18 -------
(In reply to comment #4)
> All the tests demonstrate is that you have buggy constraint, in particular
> you shouldn't use "g" constraint on something you use in gs:[%2].
> "g" is any register (fine in that case), immediate (not fine) or memory (not
> fine either in this case).
> mov al, gs:[DWORD PTR [ebp+12]]
> is what you get when this->offset is memory at ebp+12, and that of course
> doesn't assemble.  Just use "r".


OK, thanks for the workaround.

Nevertheless, this is a bug because:

without -ftree-ter optimization option,
--------------------------------------
the rtl-optimization module causes the following code, generated:

mov edx, DWORD PTR [esp+24]
mov edx, DWORD PTR [edx+4]
/APP
 # 59 "far_pointers.h" 1
.intel_syntax noprefix;     
mov gs, ax;                 
mov bl, gs:[edx];  

with -ftree-ter :
---------------
mov edx, DWORD PTR [esp+24]
/APP
 # 59 "far_pointers.h" 1
.intel_syntax noprefix;     
mov gs, ax;                 
mov bl, gs:[DWORD PTR [edx+4]]; 


(I don't want to enter in a philosophic debate)
Nevertheless, with "g" directive, this is the responsability of the compiler to
choose the good addressing mode because the developer can't know how to
anticipate regarding code generated before inline assembly.
Or, the "g" directive should be deleted from GCC specs.

Thank you again for your suggestion.

Regards,


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44288


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]