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 259823858D34; Thu, 23 Sep 2021 13:58:41 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 259823858D34
From: "amacleod at redhat dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/102463] [12 Regression] ice in
 fold_using_range::relation_fold_and_or
Date: Thu, 23 Sep 2021 13:58:41 +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: 12.0
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: blocker
X-Bugzilla-Who: amacleod at redhat dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 12.0
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-102463-4-boy0AngUx7@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-102463-4@http.gcc.gnu.org/bugzilla/>
References: <bug-102463-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
X-BeenThere: gcc-bugs@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-bugs mailing list <gcc-bugs.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Sep 2021 13:58:41 -0000

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

--- Comment #6 from Andrew Macleod <amacleod at redhat dot com> ---
That trapping routine (relation_fold_and_or)  is looking to see if there are
any relationships between dependencies that can be exploited. ie
   c_2 =3D a_6 > b_7
   c_3 =3D a_6 < b_7
   c_4 =3D c_2 && c_3
  if (c_4 !=3D 0)

when looking at c_2 and c_3, it notes that they both depend on the same 2
ssa-names,  a_6, and a_7.
It then queries whether there is a relationship between them when c_2 is [1=
,1]
and c_3 is [1,1].   If so, it then tries to apply that relation to see if t=
he
stmt can never be true or not based on that raw relation.

In this case, the 2 defining stmts are both PHI nodes, which happen to have=
 the
same 2 ssa_names in the dependency list, so it matches the pattern being lo=
oked
for:

  # ntdef_6 =3D PHI <newdef_10(2), _bfd_elf_merge_symbol_h.0_1(3)>
  # tdef_7 =3D PHI <_bfd_elf_merge_symbol_h.0_1(2), newdef_10(3)>
  _5 =3D __tdef_7 & ntdef_6

both names depend on the value of newdef_10 and _bfd_elf_merge_symbol_h.0_1=
, so
a check is being made for a relationship between op1 and op2 in those stmts.

Whats missing is that we can only check for operand relationships in range-=
ops
enabled stmts... The phi will never overtly give us a relation between the
first and second operand, so no need to check.=