From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id CB5C23858038; Thu, 14 Oct 2021 08:38:05 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org CB5C23858038 From: "aldyh at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/102736] [12 Regression] wrong code at -O1 -ftree-vrp by r12-3903 Date: Thu, 14 Oct 2021 08:38:05 +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: 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: 12.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc assigned_to Message-ID: In-Reply-To: References: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2021 08:38:05 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D102736 Aldy Hernandez changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |aldyh at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |aldyh at gcc dot gn= u.org --- Comment #3 from Aldy Hernandez --- (In reply to Andrew Macleod from comment #2) > works with --disable-tree-vrp-thread1 >=20 >=20 > Looking at the .vrp-thread1 listing, I see a lot of >=20 > Registering value_relation (_4 >=3D a.4_14) on (3->4) > Registering value_relation (path_oracle) (_5 =3D=3D iftmp.6_13) (bb4) > [1] Registering jump thread: (4, 5) incoming edge; (5, 7) joiner (7, 8) > normal (8, 9) nocopy; > Registering value_relation (path_oracle) (iftmp.6_12 =3D=3D iftmp.6_13) = (bb6) > Registering value_relation (path_oracle) (iftmp.6_12 =3D=3D iftmp.6_13) = (bb6) > [2] Registering jump thread: (6, 7) incoming edge; (7, 9) joiner; > Registering value_relation (path_oracle) (iftmp.6_12 =3D=3D iftmp.6_13) = (bb6) > [3] Registering jump thread: (6, 7) incoming edge; (7, 8) joiner (8, 9) > nocopy; > Registering value_relation (path_oracle) (_5 =3D=3D iftmp.6_13) (bb5) > Registering value_relation (path_oracle) (_5 =3D=3D iftmp.6_13) (bb5) > Registering value_relation (path_oracle) (_5 =3D=3D iftmp.6_13) (bb5) > Registering value_relation (path_oracle) (_4 < a.4_14) (bb3) > Registering value_relation (path_oracle) (_3 =3D=3D iftmp.3_15) (bb3) > Registering value_relation (path_oracle) (_4 < a.4_14) (bb3) > Registering value_relation (path_oracle) (_3 =3D=3D iftmp.3_15) (bb3) > Registering value_relation (path_oracle) (_5 =3D=3D iftmp.6_13) (bb3) What you're seeing here is the verbosity out of path_oracle::register_relat= ion for each candidate path as it's being tried. What I've been doing is avoiding dumping the details of the path solver in action, unless TDF_THREADING, but the above message is coming from the path oracle itself, which is keyed off of TDF_DETAILS. This is a bit confusing. Perhaps we should silence these messages unless TDF_THREADING? What do you think?=