https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88274
--- Comment #6 from rguenther at suse dot de <rguenther at suse dot de> --- On Fri, 30 Nov 2018, jakub at gcc dot gnu.org wrote: > 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. I think those min/max values not matching the precision are only an optimization hint. But yes, if a pass creates out-of-range values then it has to use a different type for those. Or we simply go away with honoring those hints in VRP at all...
