[Patch] Fix MIPS build failure caused by -Werror=undef
Steve Ellcey
sellcey@imgtec.com
Tue Feb 17 21:37:00 GMT 2015
On Tue, 2015-02-17 at 19:58 +0000, Maciej W. Rozycki wrote:
> There's clearly nothing Linux specific there although one might ask which
> of the two of __MIPSEB vs __MIPSEB__ is the "traditional" macro we might
> want to keep. Or maybe _MIPSEB even. I'm not sure offhand and clearly
> current GCC defines all at a time.
>
> Also I wonder if sanity checks like:
>
> #if defined (__MIPSEB) && defined (__MIPSEL)
> # error "Both __MIPSEB and __MIPSEL, endianness configuration problem?"
> #elif defined (__MIPSEB)
> # define __BYTE_ORDER __BIG_ENDIAN
> #elif defined (__MIPSEL)
> # define __BYTE_ORDER __LITTLE_ENDIAN
> #elif
> # error "Neither __MIPSEB nor __MIPSEL, endianness configuration problem?"
> #endif
>
> would make sense here too, to catch issues early on in case someone does
> something silly with `-D' or `-U'.
>
> Maciej
I wonder if we should check here or if we should check in the shared
src/glibc/string/endian.h file. We could verify that after including a
system specific bits/endian.h, __BYTE_ORDER is defined to either
__BIG_ENDIAN or __LITTLE_ENDIAN.
Maybe change this check in src/glibc/string/endian.h to have a '#else
#error' clause. Is it ever legal to not define __BYTE_ORDER?
#if __BYTE_ORDER == __LITTLE_ENDIAN
# define __LONG_LONG_PAIR(HI, LO) LO, HI
#elif __BYTE_ORDER == __BIG_ENDIAN
# define __LONG_LONG_PAIR(HI, LO) HI, LO
#endif
Steve Ellcey
More information about the Libc-alpha
mailing list