[PATCH] replace LIBGCC2_WORDS_BIG_ENDIAN with __WORDS_BIG_ENDIAN__

[Joseph S. Myers]

On Tue, 12 Oct 2010, Nathan Froyd wrote:

> The patch below eliminates the need for LIBGCC2_WORDS_BIG_ENDIAN by
> having the compiler define __WORDS_BIG_ENDIAN__ and appropriate places
> use that instead.  The motivating idea here is that the compiler should
> be queried for all target-specific knowledge when compiling target
> libraries.  I plan to replace several other macros in a similar fashion.

I don't see any documentation of this new macro in cpp.texi.  Such 
documentation is needed - and I think it needs to explain in user terms 
exactly what is meant by "word" (is it always the same as what 
__attribute__((__mode__(__word__))) gives you? what is that anyway?) so 
that the exact implications for byte ordering of integer types in memory 
are clear.  The same applies to any other macro scheme - make clear 
exactly what is being asserted about type representations by the macro 
value.

As I understand it, the only current cases in GCC where WORDS_BIG_ENDIAN 
and BYTES_BIG_ENDIAN may differ are:

* pdp11.

* arm, with -mwords-little-endian.  "Note: this option should only be used 
if you require compatibility with code for big-endian ARM processors 
generated by versions of the compiler prior to 2.8.".  It could probably 
be removed by now.

* powerpc-wrs-vxworks and powerpc-wrs-vxworksae, with -mlittle-endian / 
-mlittle, because rs6000/sysv4.h allows both endiannesses but then 
rs6000/vxworks.h undefines and redefines only BYTES_BIG_ENDIAN, so 
allowing word endianness to vary but not byte endianness.  Redefining only 
one macro is clearly a bug here.

-- 
Joseph S. Myers
joseph@codesourcery.com