https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116997
--- Comment #1 from avieira at gcc dot gnu.org --- Had a look at this and I see similar codegen for aarch64 when compiling for big-endian. If I disable tree-ifcvt (-fdisable-tree-ifvt) I end up with: MEM <unsigned long> [(void *)Ptr.0_1] = 30071062528; Which is the behaviour we want to see. This is achieved by store-merging, we should have a look at how that pass handles this. When ifcvt is enabled, lower_bitfield generates: _ifc__24 = Ptr.0_1->D.4418; _ifc__25 = BIT_INSERT_EXPR <_ifc__24, 3, 0 (11 bits)>; That gets optimized to: Ptr.0_1->D.4418 = 3; Whereas I expected that to get big-endiannised (not a word I know) to = 0x600000. I was also surprised to see that the front-end already transforms: 'if (GlobS.f2 != 3)' into '(BIT_FIELD_REF <GlobS, 32, 32> & 4292870144) != 6291456' Anyway that's as far as I got, not sure what the right solution is, should BIT_INSERT_EXPR <_ifc__24, 3, 0 (11 bits)> not fold to 0x60000 ?
