ghfeil@white.toronto.edu (Georg Feil) (11/16/89)
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)