From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id EF0803858404; Fri, 9 Sep 2022 08:15:14 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org EF0803858404 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1662711314; bh=pKU4t2UnXNHWOyje0yUelWa2WdkQ3RgUrPXi6cStq54=; h=From:To:Subject:Date:In-Reply-To:References:From; b=xR9ZpNFApK61yr+dz0Ixev3hSyLrWBOJn9r4XEp87o3ok8fyAFjYMxvjFdUtvH0wC gNkbiL4hXbSmC2qExfaRLNcHLgmZ4yMZ0sUWZKwZmVT/K9j2IAZ4hoPRXmDH9aoSuu gQCGaKr/H35AhlmtNAmxaqaU5RMJBeogOoWmG+ao= From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/106892] Wrong code at -O3 on x86_64-linux-gnu Date: Fri, 09 Sep 2022 08:15:14 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c X-Bugzilla-Version: 13.0 X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status cc keywords 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 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D106892 Richard Biener changed: What |Removed |Added ---------------------------------------------------------------------------- Status|WAITING |NEW CC| |rguenth at gcc dot gnu.org Keywords| |wrong-code --- Comment #4 from Richard Biener --- (In reply to Li Shaohua from comment #3) > Yes, I reduced it too much. Here is the new one with return value in g() > function. >=20 > a, b, c, d, e; > f[8]; > g() { > while (a) > a >>=3D 4; > return 0; > } > h(i) { > if (i >=3D '0') > return i - '0'; > } > j(i) { > b =3D 2; > for (; g() <=3D 7; b++) > if (i) { > for (; e <=3D 7; e++) { > c =3D 1; > for (; c <=3D 7; c++) { > d =3D h(b + 48); > f[-d + 4] ^=3D 3; > } > } > return; > } > } > main() { > j(1); > printf("%d\n", f[2]); > } When I apply the same "fix" to h() (add a return 0 or __builtin_unreachable= ()) the code works again. Note I think the missing return stmt isn't reached at runtime. Disabling either unswitching or loop splitting makes the issue go away, enabling both ontop of -O2 doesn't trigger it. We early inline h into j where h looks like int h (int i) { int _3; : if (i_1(D) > 47) goto ; [INV] else goto ; [INV] : _3 =3D i_1(D) + -48; // predicted unlikely by early return (on trees) predictor. return _3; : return; } which results in b.2_1 =3D b; _2 =3D b.2_1 + 48; _3 =3D h (_2); d =3D _3; becoming b.2_1 =3D b; _2 =3D b.2_1 + 48; if (_2 > 47) goto ; [34.00%] else goto ; [66.00%] : _30 =3D _2 + -48; _43 =3D _30; : # _39 =3D PHI <_43(6), _37(5)> _3 =3D _39; d =3D _3; note that the return; case results in _37 to be used which is completely random. That said, our handling of an unreachable missing return in the IL is likely counter productive. Cleaned up testcase: int a, b, c, d, e; int f[8]; int g() { while (a) a >>=3D 4; return 0; } int h(int i) { if (i >=3D '0') return i - '0'; //__builtin_unreachable (); } void j(int i) { b =3D 2; for (; g() <=3D 7; b++) if (i) { for (; e <=3D 7; e++) { c =3D 1; for (; c <=3D 7; c++) { d =3D h(b + 48); f[-d + 4] ^=3D 3; } } return; } } int main() { j(1); if (f[2] !=3D 0) __builtin_abort (); }=