CT-NG: floating point support in Newlibs printf?

[Jeppe Ledet-Pedersen]

Yann, All,

On 2010-10-25 08:54, Jeppe Ledet-Pedersen wrote:
[--SNIP--]
> If I i run "arm-unknown-eabi-cpp -dD" my toolchain defines both
> __ARMEL__, __SOFTFP__ and __VFP_FP__ which should be taken into account
> by Newlib in include/machine/ieeefp.h to use the correct floating point
> format.
[--SNIP--]

I have performed some further debugging of my floating point problems, 
but I still don't have a solution.

__IEEE_LITTLE_ENDIAN is correctly set by include/machine/ieeefp.h and 
consequently IEEE_8087 is defined in both stdlib/mprec.h and 
stdio/vfieeefp.h. The macros word0()/word1() also appears to be set 
correctly. _DOUBLE_IS_32BITS is not defined.

With my test code (http://pastebin.com/3Dsb9siL), I get the following 
output:

00 00 00 00 00 00 55 c0
a is 0.000000
00 00 55 c0 00 00 00 00
a (flipped) is -84.000000

According to "Format of VFP values" from the ARM Developer Suite 
Developer Guide 
(http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0056d/Bcfibfha.html):

"in little-endian mode, the more significant word of a two-word 
double-precision value, containing the exponent, has the higher address"

So it appears that GCC stores the double value in correct little-endian, 
VFP format but Newlib will only print it if converted to FPA format. I 
have looked through the code for _vfprint_r and _dtoa_r but haven't 
noticed anything suspicious.

Can any of you reproduce this behavior on your platforms? Suggestions to 
what could be the culprit are very welcome. Maybe I should post my 
question on the Newlib mailing list as well.

Thank you in advance.

Best regards,
Jeppe

--
For unsubscribe information see http://sourceware.org/lists.html#faq