🚀 go-pugleaf

On the 68020 version of gas 1.34 (both 'sun3' and 'generic'), the 
binary-to-ascii floating-point number conversion routine loses precision
and produces an incorrect result in some cases. In particular, trailing zeroes
that should not affect the conversion cause loss of precision.

Test case: Assemble the following near-trivial file with 
     gas bad.s -o bad.o
and examine the binary output:

------------- bad.s --------------
.data
        .double 0r4.50359962737049600000e+15
----------------------------------


The hex representation of the above number should be
     4330 0000 0000 0000

but comes out as
     432f ffff fffe 0000

instead. The Sun assembler handles this correctly. However, if
we remove the trailing zeroes from the number, gas handles it correctly as
well. If we add more trailing zeroes, the gas result gets more inaccurate.
The number above comes from gcc 1.36 compiling the MAXPOWTWO preprocessor
macro defined in <values.h> on Suns. 

The problem lies somewhere in the source files atof-m68k.c or atof-generic.c,
but these are too cryptic for me to attempt a comprehensive bug search.
A quick fix would involve stripping trailing zeroes that follow a decimal
point before starting a conversion.

Georg
-- 
Georg Feil                                            "The roof is leaking
ghfeil@white.toronto.edu                               and the wind is howling"
...if that doesn't work try one of:
{uunet,pyramid,watmath,utzoo}!utcsri!white!ghfeil
ghfeil%white.toronto.edu@relay.cs.net     (ARPA)