ieeefp.h and arm

Nick Clifton nickc@cambridge.redhat.com
Tue Nov 13 08:40:00 GMT 2001


Hi Anthony,

> I've found what looks to be a problem in newlib's ieeefp.h (which
> libgcj borrows).
>
>      The arm bits look like this:
> 
> #if defined(__arm__) || defined(__thumb__)
> /* ARM always has big-endian words.  Within those words the byte ordering
>    will be big or little endian depending upon the target.  */
> #define __IEEE_BIG_ENDIAN
> #ifdef __ARMEL__
> #define __IEEE_BYTES_LITTLE_ENDIAN
> #endif
> #endif
> 
>      This seems to be at odds with what gcc/config/arm.h says:
> 
> #define CPP_ENDIAN_SPEC "\
> %{mbig-endian:								\
>   %{mlittle-endian:							\
>     %e-mbig-endian and -mlittle-endian may not be used together}	\
>   -D__ARMEB__ %{mwords-little-endian:-D__ARMWEL__} %{mthumb:-D__THUMBEB__}}\
> %{mlittle-endian:-D__ARMEL__ %{mthumb:-D__THUMBEL__}}			\
> %{!mlittle-endian:%{!mbig-endian:%(cpp_endian_default)}}		\
> "

Look a little further on in arm.h...

  /* Define this if most significant word of doubles is the lowest numbered.
     This is always true, even when in little-endian mode.  */
  #define FLOAT_WORDS_BIG_ENDIAN 1

So although -mwords-little-endian can be set, it will only affect the
word order of multiword integer objects.  Multiword floating point
objects will always be stored in big-word-endian order.


I am not sure why the arm target even supports the
-mwords-little-endian switch.  It is probably historical, and I doubt
if it is used by anyone these days.

Cheers
        Nick





More information about the Newlib mailing list