http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60490
--- Comment #7 from Chandler Carruth <chandlerc at gmail dot com> --- (In reply to Jakub Jelinek from comment #6) > Just look what GCC does? > Say on x86_64 it does: > gcc -E -dD -xc /dev/null | grep ENDIAN > #define __ORDER_LITTLE_ENDIAN__ 1234 > #define __ORDER_BIG_ENDIAN__ 4321 > #define __ORDER_PDP_ENDIAN__ 3412 > #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__ > #define __FLOAT_WORD_ORDER__ __ORDER_LITTLE_ENDIAN__ > on e.g. ppc64 it does: > gcc -E -dD -xc /dev/null | grep ENDIAN > #define __ORDER_LITTLE_ENDIAN__ 1234 > #define __ORDER_BIG_ENDIAN__ 4321 > #define __ORDER_PDP_ENDIAN__ 3412 > #define __BYTE_ORDER__ __ORDER_BIG_ENDIAN__ > #define __FLOAT_WORD_ORDER__ __ORDER_BIG_ENDIAN__ > Don't have access to PDP nor built cross-compiler for that, but it would > expectably define __BYTE_ORDER__ to __ORDER_PDP_ENDIAN__. Cool, seems like we could easily support both this and consistently defining __BIG_ENDIAN__ and __LITTLE_ENDIAN__ in Clang. Is there any reason to specifically avoid defining the latter two on systems where __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__ (or little respectively)? If there is a reason to not do so, we probably shouldn't do it in Clang either. If there isn't a reason, maybe both GCC and Clang should do so?
