[Bug tree-optimization/109934] [14 Regression] Wrong code at -O3 on x86_64-linux-gnu

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

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |amacleod at redhat dot com
           Assignee|unassigned at gcc dot gnu.org      |aldyh at gcc dot gnu.org

--- Comment #2 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
Woah...this is a latent bug in irange::invert that seems to have been here for
a very long time.

In the loop unswitching code we do:

    false_range = true_range;
    if (!false_range.varying_p ()
        && !false_range.undefined_p ())
      false_range.invert ();

...and get the false_range all wrong:

(gdb) p debug(false_range)
[irange] unsigned int [44, 44][111, 111][222, 222] NONZERO 0xff
$40 = void
(gdb) n
(gdb) n
(gdb) n
(gdb) n
(gdb) p debug(false_range)
[irange] unsigned int [44, +INF]

In no universe is the inverse of the false_range equal to [44, +INF].  Whoops.

This craziness happens here:

  if (m_num_ranges == m_max_ranges
      && lower_bound () != type_min
      && upper_bound () != type_max)
    {
      m_base[1] = type_max;
      m_num_ranges = 1;
      return;
    }

I have no idea what we were trying to do here, but it's clearly wrong.  This
probably never triggered because the old legacy code didn't use this code, and
the new code used int_range<255> (int_range_max) which made it extremely
unlikely this would ever trigger.