jfc@athena.mit.edu (John F Carr) (09/17/90)
There is a bug in the floating point code generator for the 68881
(/usr/lib/libfp.a(f881gen.o)). In some cases, single precision
floats in general registers can cause bad code generation (register
0 is marked as available for address calculations when it is [1]
not a valid base register for address calculations [2] in use).
Apparently hc doesn't generate much code that triggers this bug,
but gcc does. This is a fix (it will be making its way though
official channels to IBM as well).
*** /source/bsd-4.3/rt/usr.lib/libfp/genfp/f881gen.c Fri Jun 16 17:35:44 1989
--- f881gen.c Mon Sep 17 01:53:39 1990
***************
*** 309,315 ****
if (is_scratchg(gi, (rr & 0x0f)))
fp_free_genr(gi, (rr & 0x0f));
! if (is_scratchg(gi, (rr >> 4)))
fp_free_genr(gi, (rr >> 4));
return (i);
--- 309,315 ----
if (is_scratchg(gi, (rr & 0x0f)))
fp_free_genr(gi, (rr & 0x0f));
! if (is_double(rr) && is_scratchg(gi, (rr >> 4)))
fp_free_genr(gi, (rr >> 4));
return (i);
--
--John Carr (jfc@athena.mit.edu)brunner@bullhead.uucp (09/19/90)
In article <1990Sep17.061429.27757@athena.mit.edu> jfc@athena.mit.edu (John F Carr) writes: > >There is a bug in the floating point code generator for the 68881 >(/usr/lib/libfp.a(f881gen.o)). In some cases, single precision >floats in general registers can cause bad code generation (register >0 is marked as available for address calculations when it is [1] >not a valid base register for address calculations [2] in use). >Apparently hc doesn't generate much code that triggers this bug, >but gcc does. This is a fix (it will be making its way though >official channels to IBM as well). > John, Thanks for the patch, could you mail me a test case? Thanks in advance! #include <std/disclaimer.h> Eric Brunner, Consultant, IBM AWD Palo Alto (415) 855-4486 inet: brunner@monet.berkeley.edu uucp: uunet!ibmsupt!brunner trying to understand multiprocessing is like having bees live inside your head.