[Bug target/46275] -masm=intel -fPIC causes global offset table issues

[hezekiahehud at gmail dot com]

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

--- Comment #5 from hezekiahehud at gmail dot com 2010-11-02 19:08:32 UTC ---
The source code in question is for an anti-virus product, originally targeting
Windows.  It contains a great deal of inline assembly code, all of which is
written in Intel syntax.  The reason for the existing GCC + Intel compiler mix
is because the Intel compiler happily accepts the same Intel-style assembly
syntax and the same syntax for block-scoped assembly as MSVC.  However, we want
to move away from the Intel compiler.

So, we are working on a port to pure GCC and have worked our way around the
block-syntax and other MSVC-and-Intel-compiler-specific-syntax related issues,
but we cannot justify maintaining two copies of the same large set of inline
assembly code, one in AT&T and one in Intel syntax.  Hence, the requirement for
-masm=intel.

I realize that -masm=intel might not be a widely used option, but does that
really matter?  Ultimately, the compiler is producing bad output that will kill
any 32-bit program that uses globals compiled with -masm=intel -fPIC.  I once
again admit my ignorance of the relative severity of GCC bugs, but that seems
pretty bad to me.


(In reply to comment #4)
> -masm=intel is really only needed if you are going to do some post processing
> of the assembly code or want to read the assembly code in the Intel (non AT&T)
> format.  It should not change the code generation or the ABI.  Also it should
> be noted that the Intel compiler under GNU/Linux outputs assembly code in the
> AT&T format by default.  Also note the generated object files will be the same. 
> 
> From what you mentioned in comment #3, I don't see a reason to use -masm=intel.
>  Do you post process the assembly code?