jjc@UUNET.UU.NET (James Clark) (05/23/89)
I reported a problem with 386 floating point subtraction to you
yesterday. The problem was that this program:
double foo()
{
return 1.0;
}
main()
{
double x = 5.0;
x -= foo();
printf("%g\n", x);
}
output -4 rather than 4 when compiled by gcc 1.35 configured for the
386 with gas.
The following patch seems to fix this problem:
*** out-i386.c Tue May 23 11:57:18 1989
--- aux-output.c Tue May 23 12:01:15 1989
***************
*** 140,150 ****
/* Here we want the "reversed" insn, fsubr or fdivr.
But there is an assembler bug in all 80386 assemblers
which exchanges the meanings of fsubr and fsub, and of fdivr and fdiv!
So use the "unreversed" opcode (which will assemble into
the "reversed" insn). */
! rev = op;
while (*rev && *rev != '%')
fputc (*rev++, asm_out_file);
/* fp_pop_level--; */
--- 140,150 ----
/* Here we want the "reversed" insn, fsubr or fdivr.
But there is an assembler bug in all 80386 assemblers
which exchanges the meanings of fsubr and fsub, and of fdivr and fdiv!
So use the "unreversed" opcode (which will assemble into
the "reversed" insn). */
! /* rev = op; */
while (*rev && *rev != '%')
fputc (*rev++, asm_out_file);
/* fp_pop_level--; */
I don't completely understand what's going on here, but the patch
works on all the examples that I've tried.
James Clark
jjc@jclark.uucp