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