This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] replace LIBGCC2_WORDS_BIG_ENDIAN with __WORDS_BIG_ENDIAN__
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Nathan Froyd <froydnj at codesourcery dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Tue, 12 Oct 2010 23:48:15 +0000 (UTC)
- Subject: Re: [PATCH] replace LIBGCC2_WORDS_BIG_ENDIAN with __WORDS_BIG_ENDIAN__
- References: <20101012204838.GE24720@nightcrawler>
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