https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #28 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Wilco from comment #27) > (In reply to Eric Botcazou from comment #22) > > > Is it really pure RTL, therefore not used in tree? So the above patch > > > using > > > BITS_BIG_ENDIAN for tree stuff would be incorrect to use it? > > > > I wouldn't say incorrect, just inappropriate and unnecessary. And, yes, it > > isn't used at the tree level and should stay so IMO. BYTES_BIG_ENDIAN alone > > already implicitly enforces a numbering on bits. > > I mean incorrect as in the optimization would still trigger and give > incorrect results if BITS_BIG_ENDIAN == BYTES_BIG_ENDIAN (given that > BITS_BIG_ENDIAN has no bearing on the bitfield offsets used on tree level). Given that it matters for /* If I2 is setting a pseudo to a constant and I3 is setting some sub-part of it to another constant, merge them by making a new constant. */ if (i1 == 0 ... if (GET_CODE (dest) == ZERO_EXTRACT) { ... if (BITS_BIG_ENDIAN) offset = GET_MODE_PRECISION (dest_mode) - width - offset; and VN tries to do sth similar I wonder if it does matter after all... That said, the docs also refer to 'bit-field instructions' but do not elaborate further -- I guess zero_extract is such but I'd have guessed BIT_FIELD_REF (on trees) is as well. But yes, RTL expansion adjusts things based on BITS_BIG_ENDIAN so it looks like GENERIC doesn't care (or assumes BITS_BIG_ENDIAN == BYTES_BIG_ENDIAN).