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?
