Repost due to spamcop block of comcast.net:
Problem synopsis is that on intel targets when using -masm=intel,
it incorrectly appends the ATT-style length suffix onto the x87
opcodes. This used to be (incorrectly) accepted by GNU as, but
it is no longer in the 2.11.x series.
This is easily verified with
make check RUNTESTFLAGS="--tool_opts '-masm=intel'"
which will fail on almost every floating point test.
The fix is simple and attached below.
make bootstrap on i686-pc-cygwin without BOOT_CFLAGS="-masm=intel"
I also ran
make check RUNTESTFLAGS="--tool_opts '-march=athlon -masm=intel'"
before and after this patch:
=== gcc Summary ===
-# of expected passes 16279
-# of unexpected failures 1088
+# of expected passes 17574
+# of unexpected failures 223
# of unexpected successes 1
# of expected failures 65
-# of unresolved testcases 505
+# of unresolved testcases 81
# of unsupported tests 40
Almost the remaining failures these are due to use of the length extension
for "rep movs/stos/...", but I consider this a binutils .intel-syntax bug.
In Intel mode, it no longer seems to accept the masm alias 'rep movsd'
for incredibly unwieldly 'rep movs dword ptr es:[edi],dword ptr ds:[esi]'.
Ditto for the rest of the 'rep' instructions.
I will contact those folks soon.
Kelley Cook <no write privledges>
FWIW, this bug is also present in the 3.0 tree.
2002-02-23 Kelley Cook <[EMAIL PROTECTED]>
* config/i386/i386.c: Don't append ATT-style length suffixs to
x87 opcodes when in Intel mode.
Index: config/i386/i386.c
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/config/i386/i386.c,v
retrieving revision 1.367
diff -u -r1.367 i386.c
--- config/i386/i386.c 21 Feb 2002 23:06:16 -0000 1.367
+++ config/i386/i386.c 23 Feb 2002 18:10:25 -0000
@@ -5722,6 +5722,11 @@
if (STACK_REG_P (x))
return;
+ /* Likewise if using Intel opcodes. */
+
+ if (ASSEMBLER_DIALECT == ASM_INTEL)
+ return;
+
/* this is the size of op from size of operand */
switch (GET_MODE_SIZE (GET_MODE (x)))
{
