Re: Problem with printf and float

[Pavel Pisa <ppisa4lists at pikron dot com>]

On Monday 25 October 2010 21:21:41 Jeppe Ledet-Pedersen wrote:
> Hi everybody,
>
> This question was originally posted on the crossgcc mailing list, but my
> problem appears to be related to Newlib so I'll repost it here. My
> original question can be found at
> http://sourceware.org/ml/crossgcc/2010-10/msg00147.html
>
> I have successfully compiled a toolchain for my arm7tdmi with
> crosstool-NG. I use GCC 4.5.1, Newlib CVS and Binutils 2.20.1. I have
> enabled the EABI and software floating point.

Hello Jeppe,

I am replying, because we have problem in similar area
but it was vice verse. The bad NEWlib access to doubles
when GCC compiled correctly FPA format but NEW lib
accessed the first word as least significant.
There has been more problems in this area with NEWlib
1.18.0. Some third party attempts to fix right
byte endianing from NEWlib headers even caused
total mess in FP endianess.

I hoped, that changes incorporated into actual NEW lib
CVS should work for all cases (analyzed together
with GCC-4.4.4 sources).

The core components which has to correspond are

----------------------------------------
/newlib/libc/include/machine/ieeefp.h
----------------------------------------
#ifdef __VFP_FP__
# ifdef __ARMEL__
#  define __IEEE_LITTLE_ENDIAN
# else
#  define __IEEE_BIG_ENDIAN
# endif
#else
# define __IEEE_BIG_ENDIAN
# ifdef __ARMEL__
#  define __IEEE_BYTES_LITTLE_ENDIAN
# endif
#endif
#endif

----------------------------------------
newlib/libc/include/machine/endian.h
----------------------------------------
#ifndef BYTE_ORDER
#if defined(__IEEE_LITTLE_ENDIAN) || defined(__IEEE_BYTES_LITTLE_ENDIAN)
#define BYTE_ORDER LITTLE_ENDIAN
#else
#define BYTE_ORDER BIG_ENDIAN
#endif
#endif

The constants are used in

  newlib/libm/common/fdlibm.h
  newlib/libc/stdio/vfieeefp.h

The second one uses curious renaming to source original architecture
influenced

  IEEE_8087 or IEEE_MC68k for __IEEE_LITTLE_ENDIAN or __IEEE_BIG_ENDIAN

If your code and NEWlib build use same set of switches and defines

> If I i run "arm-unknown-eabi-cpp -dD" my toolchain defines both
> __ARMEL__, __SOFTFP__ and __VFP_FP__ which should be taken into account

then the __VFP_FP__ and __ARMEL__ should select right defines
in ieeefp.h -> __IEEE_LITTLE_ENDIAN defined and
__IEEE_BYTES_LITTLE_ENDIAN left unset and all parts should interpret
doubles same way. I would suggest to check, that the right build
options for newlib build are selected.
You can modify

newlib/libc/stdio/vfprintf.c

with

#ifdef __IEEE_LITTLE_ENDIAN 
 #warning __IEEE_LITTLE_ENDIAN is selected
#endif
#ifdef __IEEE_BIG_ENDIAN
 #warning __IEEE_BIG_ENDIAN is selected
#endif
#ifdef __IEEE_BYTES_LITTLE_ENDIAN
 #warning __IEEE_BYTES_LITTLE_ENDIAN is selected
#endif
#ifdef IEEE_8087
 #warning IEEE_8087 is selected
#endif
#ifdef IEEE_MC68k
 #warning IEEE_MC68k is selected
#endif

and you should see only __IEEE_LITTLE_ENDIAN and IEEE_8087
for your variant build. If you use multilib, then you should
check, that you really use that library variant which
prints "__IEEE_LITTLE_ENDIAN is selected" and "IEEE_8087 is selected"

Best wishes,


                Pavel Pisa

==================================================
 PiKRON s.r.o.       Phone/Fax: +420 2 84684676
 Kankovskeho 1235    Phone:     +420 2 84684676
 182 00 Praha 8      WWW:   http://www.pikron.com/
 Czech Republic      e-mail:  pikron@pikron.com
==================================================

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