From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 832BB3858439; Tue, 19 Jul 2022 07:27:46 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 832BB3858439 From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/106187] armhf: Miscompilation at O2 level (O0 / O1 are working) Date: Tue, 19 Jul 2022 07:27:46 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 10.4.0 X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED 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: 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: Tue, 19 Jul 2022 07:27:46 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D106187 --- Comment #28 from Richard Biener --- (In reply to Richard Earnshaw from comment #26) > git bisect points to commit r11-9688 resolving the issue. Before that > commit the ivopts pass generates: >=20 > ivtmp.761_217 =3D (unsigned int) &au; > _222 =3D &bu + 4; > ivtmp.767_220 =3D (unsigned int) _222; > _225 =3D (unsigned int) &au; > _228 =3D _225 + 16; >=20 > [local count: 858993457]: > # prephitmp_136 =3D PHI > # prephitmp_32 =3D PHI > # ivtmp.761_278 =3D PHI > # ivtmp.767_218 =3D PHI > _16 =3D prephitmp_32 ^ prephitmp_136; > _223 =3D (void *) ivtmp.761_278; > MEM[(unsigned int *)_223] =3D _16; > ivtmp.761_216 =3D ivtmp.761_278 + 4; > if (ivtmp.761_216 !=3D _228) > goto ; [75.00%] > else > goto ; [25.00%] >=20 > [local count: 644245086]: > _230 =3D (void *) ivtmp.761_216; > pretmp_120 =3D MEM[(unsigned int *)_230]; > _229 =3D (void *) ivtmp.767_218; > pretmp_18 =3D MEM[(unsigned int *)_229]; > ivtmp.767_219 =3D ivtmp.767_218 + 4; > goto ; [100.00%] >=20 > And once that patch is applied we get: >=20 > ivtmp.761_217 =3D (unsigned int) &au; > ivtmp.766_220 =3D (unsigned int) &bu; > _223 =3D (unsigned int) &au; > _225 =3D _223 + 16; >=20 > [local count: 858993457]: > # prephitmp_136 =3D PHI > # prephitmp_32 =3D PHI > # ivtmp.761_278 =3D PHI > # ivtmp.766_218 =3D PHI > _16 =3D prephitmp_32 ^ prephitmp_136; > _222 =3D (void *) ivtmp.761_278; > MEM[(unsigned int *)_222] =3D _16; > ivtmp.761_216 =3D ivtmp.761_278 + 4; > if (ivtmp.761_216 !=3D _225) > goto ; [75.00%] > else > goto ; [25.00%] >=20 > The main difference being that in the 'bad' code we start with &bu + 4, > while in the good code we start with &bu. >=20 > I'm afraid I don't know enough about this code to take this further. Ric= hi? There's no functional difference, you omitted BB9 after the patch which for me looks like [local count: 644245086]: # PT =3D { D.22767 } _228 =3D (voidD.73 *) ivtmp.741_281; [t.ii:2167:17] pretmp_155 =3D MEM[(unsigned intD.11 *)_228]; [t.ii:2167:26] ivtmp.746_28 =3D ivtmp.746_299 + 4; # PT =3D { D.22768 } _227 =3D (voidD.73 *) ivtmp.746_28; [t.ii:2167:26] pretmp_183 =3D MEM[(unsigned intD.11 *)_227]; goto ; [100.00%] so we changed from post-increment to pre-increment of 4 - the accesses happen to the same memory location. I'm dumping with -alias-uid-lineno and alias info looks fine to me here. It might very well be that the change above triggers a bug elsewhere. Does reverting the "fixing" revision make the issue appear on trunk as well? The code at RTL expansion time looks reasonable (also from an aliasing POV), if -fno-strict-aliasing fixes it, does -fno-schedule-insn{,2} also?=