https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88274
--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> --- With additional -mbranch-cost=1 the gimple dumps are identical on x86_64 with -m32 until reassoc1, which decides differently for some reason - diff from powerpc64 to x86_64: -Optimizing range tests _7 -[3, 3] and -[5, 5] - into (_7 + 4294967293 & 4294967293) != 0 -Rank for _38 is 458754 -Width = 1 was chosen for reassociation -Width = 1 was chosen for reassociation -Removing basic block 7 ... I guess one bug here is in reassoc pass, if we have these weird types that don't have precision of the corresponding mode, we should have probably cast it to some normal integral type before doing the + 429467293 etc. on it, that is probably UB on such an IL. The other issue is that the vrp code shouldn't ICE on code like: reload_type _7; reload_type _38; reload_type _39; _7 = MEM[base: _42, offset: 16B]; _38 = _7 + 4294967293; _39 = _38 & 4294967293; where reload_type is unsigned type with range [0, 15] and precision 4. I haven't managed to create a testcase where it would trigger through invalid code though so far.
