This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: CPP macro for Byte-order
- From: Joe Buck <jbuck at synopsys dot COM>
- To: gdr at codesourcery dot com (Gabriel Dos Reis)
- Cc: gcc at gcc dot gnu dot org
- Date: Thu, 17 Jan 2002 12:15:23 -0800 (PST)
- Subject: Re: CPP macro for Byte-order
Gaby writes:
> I'm currently working on the numeric_limits<> support for floating
> point types (mainly for things like NaNs, SNaNs, Infinities,
> subnormals and such) in the C++ runtime system. I would like to know
> whether there is a CPP macro that defines the endianness selected for
> compiling a given program under a given OS. Any hints?
There's nothing that I know of that's provided standard by the OS.
And clearly configure won't work because of cross-compilation.
On the other hand, the gcc backends define BITS_BIG_ENDIAN,
BYTES_BIG_ENDIAN, and WORDS_BIG_ENDIAN (you would want BYTES_BIG_ENDIAN to
solve the problem of detecting NaNs and the like). Perhaps these
definitions can just be collected, with appropriate ifdefs based on
preprocessor symbols defined by gcc, so that correct endian-ness will be
selected on all ports and OSes where we have a backend.
If this approach is followed (define a macro based on the port, determine
the port by preprocessor constants that gcc defines for that port), then
it would be a good idea to cause a syntax error to be generated if someone
tries to build it for an unsupported port.
Another approach, that would impose a bit of runtime overhead, would be
to have a runtime test. Something like
const int __endian_detect = 1;
inline bool __little_endian() { return *(char *)&__endian_detect == 1;}
In principle the optimizer can constant-fold this, so perhaps there would
not be any runtime overhead. If so, it would be a good solution.
There would be an issue with ports in which int and char are the same
size (the DSP targets: c4x and dsp16xx).