https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105432
--- Comment #11 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The trunk branch has been updated by Aldy Hernandez <al...@gcc.gnu.org>: https://gcc.gnu.org/g:75bbc3da3e5f75f683fa33e309045c582efd20eb commit r13-60-g75bbc3da3e5f75f683fa33e309045c582efd20eb Author: Aldy Hernandez <al...@redhat.com> Date: Fri Apr 29 22:46:25 2022 +0200 Denormalize VR_VARYING to VR_RANGE before passing it to set_range_info_raw. We are ICEing in set_range_info_raw because value_range_kind cannot be VR_VARYING, since SSA_NAME_RANGE_TYPE can only hold VR_RANGE / VR_ANTI_RANGE. Most of the time setting a VR_VARYING as a global range makes no sense. However, we can have a range spanning the entire domain (VR_RANGE of [MIN,MAX] which is essentially a VR_VARYING), if the nonzero bits are set. This was working before because set_range_info_raw allows setting VR_RANGE of [MIN, MAX]. However, when going through an irange, we normalize this to a VR_VARYING, thus causing the ICE. It's interesting that other calls to set_range_info with an irange haven't triggered this. One solution would be to just ignore VR_VARYING and bail, since set_range_info* is really an update of the current range semantic wise. After all, we keep the nonzero bits which provide additional info. But this would be a change in behavior, so not suitable until after GCC 12 is released. So in order to keep with current behavior we can just denormalize the varying to VR_RANGE. Tested on x86-64 Linux. PR tree-optimization/105432 gcc/ChangeLog: * tree-ssanames.cc (set_range_info): Denormalize VR_VARYING to VR_RANGE before passing a piecewise range to set_range_info_raw.
