This is the mail archive of the
crossgcc@sourceware.org
mailing list for the crossgcc project.
See the CrossGCC FAQ for lots
more information.
Re: CT-NG: floating point support in Newlibs printf?
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