From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 731813858C39; Fri, 19 Nov 2021 10:09:26 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 731813858C39 From: "aldyh at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/103088] [12 regression] 500.perlbench from spec 2017 fails since r12-4698 Date: Fri, 19 Nov 2021 10:09:26 +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: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 12.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: 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: Fri, 19 Nov 2021 10:09:26 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D103088 --- Comment #13 from Aldy Hernandez --- (In reply to Tamar Christina from comment #11) > Historically it has always only been for the test dataset with the problem > Aldy encountered before with the signed zeros. See > https://www.spec.org/cpu2017/Docs/benchmarks/500.perlbench_r.html at the > section for GCC and -Ofast. >=20 > train and ref used to work fine before. It may be perfectly valid that we > need it now for the rest too, but it's unclear to me if that's due to a n= ew > valid transformation or an invalid one. Let's assume -ffast-math is supposed to work with ref for the time being, or until I run out of cycles :). I've reduced the failure to 2 jump threads, but unfortunately they're both correct, so we can only conclude the threader is correct. There could stil= l be a latent bug downstream. Here are some notes on reproducing. Ref takes 15 minutes to complete, but the problematic output can be seen wi= thin the first minute. The NaN output is from the diffmail.pl execution diffmai= l.pl 4 800 10 17 19 300. The problem is Perl_pp_ge() in pp.c may be miscompiled. On r12-5346, it can be reduced to: $ rm pp.o $ specmake OPTIMIZE=3D"-O3 -ffast-math -fdisable-tree-threadfull2 -fdisable-tree-ethread -fdisable-tree-thread1 -fdisable-tree-thread2 -fno-tree-dominator-opts -fdbg-cnt=3Dregistered_jump_thread:173-173:175-175" That is, turn off all jump threaders except threadfull1. If we look for dbgcnt in pp.c.111t.threadfull1, we can see: ***dbgcnt: lower limit 173 reached for registered_jump_thread.*** ***dbgcnt: upper limit 173 reached for registered_jump_thread.*** [173] Registering jump thread: (36, 39) incoming edge; (39, 40) normal (= 40, 42) nocopy;=20 path: 36->39->40->42 SUCCESS This corresponds to this path: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D BB 36 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [local count: 584543650]: if (iftmp.546_109 < iftmp.547_110) goto ; [34.00%] else goto ; [66.00%] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D BB 39 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [local count: 787582387]: # _111 =3D PHI <_69(20), -1(35), _77(23), _88(25), 1(36), _98(28), 2(37= ), 0(38), 1(26), -1(21)> _18 =3D _111 & 2; iftmp.533_35 =3D _18 =3D=3D 0; =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D BB 40 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [local count: 953267993]: # iftmp.533_22 =3D PHI if (iftmp.533_22 !=3D 0) goto ; [50.00%] else goto ; [50.00%] We can clearly conclude iftmp.533_22 !=3D 0 and thread through BB42. The #175 thread is a virtually identical sequence. Both are correct.=