From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 814383858D37; Tue, 23 May 2023 10:41:16 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 814383858D37
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1684838476;
	bh=lLKsUCqHKYvYSALIz6WF4o0BWwu+PFGeF6dw6ioJTQ0=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=t9MA3TfAbrpbUAhxSBhu1KcbRKb1bXC0uayrUNiYwai596cKvwWbuuFNcYD33Eort
	 oeXiVVzK7fopuqWjFiTeXS7Mx7KEnK3ee9ePbCX9TPbwHW514pB+Ol4KPwJelLmf8z
	 QfP8gaTnkQnfedogD7xDChB2rzDp1SIdbO/Dm8Kc=
From: "aldyh at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/109934] [14 Regression] Wrong code at -O3 on
 x86_64-linux-gnu
Date: Tue, 23 May 2023 10:41:15 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 14.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: aldyh at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: aldyh at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 14.0
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: cc assigned_to
Message-ID: <bug-109934-4-b6vmdZsAHZ@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-109934-4@http.gcc.gnu.org/bugzilla/>
References: <bug-109934-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

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

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 gn=
u.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 =3D 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 =3D 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].  Whoo=
ps.

This craziness happens here:

  if (m_num_ranges =3D=3D m_max_ranges
      && lower_bound () !=3D type_min
      && upper_bound () !=3D type_max)
    {
      m_base[1] =3D type_max;
      m_num_ranges =3D 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.=