[Bug tree-optimization/107312] [13 Regression] ICE in verify_range, at value-range.cc:1172, called from range_true_and_false since r13-3193-g8b6bcedc88d54415

["aldyh at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107312

Aldy Hernandez <aldyh at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |amacleod at redhat dot com

--- Comment #2 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
Wow, a seemingly innocent change causing an ICE.

range_true_and_false() returns a range of [0,1], which for a 1-bit signed
integer gets passed to the irange setter as [0, -1].  These endpoints are out
of order and cause an ICE.  Through some dumb luck, the legacy code swaps out
of order endpoints, because old VRP would sometimes pass endpoints reversed,
depending on the setter to fix them.  This swapping does not happen for
non-legacy, hence the ICE.

The right thing to do (apart from killing legacy and 1-bit signed integers
;-)), is to avoid passing out of order endpoints for 1-bit signed integers. 
For that matter, a range of [-1, 0] for 1-bit signed types is VARYING,
similarly for [0,1] for 1-bit unsigned types.