https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #19 from Wilco <wilco at gcc dot gnu.org> --- (In reply to Segher Boessenkool from comment #18) > Well, it is always possible to generate code with the opposite endianness to > what the hardware "wants". It just won't be very fast code. > > BITS_BIG_ENDIAN is just a convenience to the target code writer. The other > four do matter, and are quite obvious really (and all four are necessary). What I'm suggesting is that if you have a non-standard endian layout (eg. FLOAT_WORDS_BIG_ENDIAN, WORDS_BIG_ENDIAN and REG_WORDS_BIG_ENDIAN are not the same as BYTES_BIG_ENDIAN), optimizations which depend the particular layout should be disabled. There are far too few occurrences of these macros to believe that all possible combinations will work correctly on all optimizations that rely on it.
