https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #16 from Wilco <wilco at gcc dot gnu.org> --- (In reply to Richard Biener from comment #8) > So I think part of a fix would be the following. Not sure if > REG_WORDS_BIG_ENDIAN or FLOAT_WORDS_BIG_ENDIAN come into play. > With the fix we no longer simplify this for aarch64 since > BITS_BIG_ENDIAN is 0 even in BE mode. A conservative fix to only do this for little endian would be fine given one shouldn't really do this kind of low-level hacking frequently. I guess FLOAT_WORDS_BIG_ENDIAN will matter too since you could store a double and read back part of it as a bitfield (or store a __int128 bitfield and read a double back). No idea why it would use BITS_BIG_ENDIAN > That is, not sure if BIT_FIELD_REF <_2, 16, 14> would be correct as suggested > for aarch64_be because of that BITS_BIG_ENDIAN setting. Possibly - but then <_2, 16, 0> doing a right shift by 16 would be an incorrect expansion for big-endian. So something is wrong there... I think we need to simplify the many BIG_ENDIAN macros so it is feasible to get big-endian to work reliably on all targets. There seem to be far too many options which affect too many unrelated things. Big-endian is fundamentally about memory byte ordering, so allowing to different byte/bit orderings in registers just makes things overly complex without any benefit.
