This is the mail archive of the gcc-help@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]

Gnu assembler fsub "bug" status


Hi there,

I happened across the gas bug in which it produces the wrong opcodes
for the non-commutative FP arithmetic instructions where %st(0) is the
source register. While looking into the problem and how to avoid it, I
blogged about what I found (at
http://www.mindfruit.co.uk/2012/03/trouble-with-fsub.html). I was
wondering about the current state of play regarding the issue?

It seems to me that there are three options for hand-assembly writers
to deal with this, either by compiling binutils with
CPPFLAGS=-DSYSV386_COMPAT (useful if you want correct instructions in
AT&T syntax in objdump), assembling with 'as' using -mmnemonic=intel
or specifying the directive .intel_mnemonic in the source. However,
it's really not clear (to me, at least) from the docs or Honiju Lu's
patches what the effects of using the last two options are, since it
appears to switch on intel syntax if you specify intel mnemonic; and
further, those flags are set equal to !SYSV386_COMPAT as well.

I was wondering if you could elaborate on what that means for my
assembly code? If I specify .intel_mnemonic (and therefore get
.intel_syntax), have all my operands changed place? If this is
well-trodden ground, perhaps you could point me to some documentation
which would clear things up for me, please? Is it possible to have
AT&T syntax yet have "fixed" FP opcodes?

Regards

Michael


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