From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 9B2873858C52; Sun, 19 Feb 2023 03:55:40 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9B2873858C52 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1676778940; bh=D96cVz9tDAHZL1I5kS+GgUqD52vsbtl9d16bq9cJalk=; h=From:To:Subject:Date:In-Reply-To:References:From; b=T3EzMaTA+yeUKgta0vQ7xpn2QJv6I9DD4H77LmKk50phv4kklx7R8OPuOpe5zxzT1 QjPea/PR67bMeqohsVq/rjeTbnHT0UfxHKdniYX/Kaim/aIqb7MvkSGD7ikbY0q/hk SGwz6Nx/0NmLtCdO7pRGaGBYC8DyQnp/CJuQSwt8= From: "qrzhang at gatech dot edu" To: gcc-bugs@gcc.gnu.org Subject: [Bug sanitizer/108845] Unnecessary signed integer overflow checks Date: Sun, 19 Feb 2023 03:55:39 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: sanitizer X-Bugzilla-Version: unknown X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: qrzhang at gatech dot edu 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 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D108845 --- Comment #4 from Qirun Zhang --- (In reply to Qirun Zhang from comment #3) > (In reply to Jakub Jelinek from comment #2) > > I'm not convinced it is a good idea. > > Sure, in the above case it is obvious it will never trigger, but if we = say > > use ranger to decide if the operation can or can't overflow, then VRP i= s in > > many cases based on assumptions which only hold for valid code, but > > sanitizers actually want to diagnose invalid code. >=20 >=20 > Thanks! >=20 > Here is another (similar) example. Earlier versions of GCC will not inje= ct > UBSAN_CHECK_ADD. However, the latest version of GCC will. >=20 > the code example: > =3D=3D=3D=3D=3D=3D > void main() { > int a =3D 0; > for (; a !=3D 2; a++) > ; > } > =3D=3D=3D=3D=3D=3D >=20 > Compile with "gcc-11 -fsanitize=3Dsigned-integer-overflow -O3=20 > -fdump-tree-optimized", we got no UBSAN checks: >=20 > =3D=3D=3D=3D=3D=3D > void main () > { > int a; >=20 > [local count: 118111600]: >=20 > [local count: 955630225]: > # a_6 =3D PHI <1(3), 0(2)> > a_3 =3D a_6 + 1; > if (a_3 !=3D 2) > goto ; [87.64%] > else > goto ; [12.36%] >=20 > [local count: 118111600]: > return; >=20 > } > =3D=3D=3D=3D=3D=3D >=20 > Compile with "gcc-trunk -fsanitize=3Dsigned-integer-overflow -O3=20 > -fdump-tree-optimized", we got one: >=20 > =3D=3D=3D=3D=3D=3D > void main () > { > int a; >=20 > [local count: 118111600]: >=20 > [local count: 955630225]: > # a_5 =3D PHI > a_3 =3D .UBSAN_CHECK_ADD (a_5, 1); > if (a_3 !=3D 2) > goto ; [89.00%] > else > goto ; [11.00%] >=20 > [local count: 118111600]: > return; >=20 > } > =3D=3D=3D=3D=3D=3D >=20 > $ gcc-trunk -v > gcc version 13.0.1 20230218 (experimental) [master r13-6132-g32b5875c911] > (GCC) I did a bisect. For the testcase provided in comment #3, the behavior was introduced in the following commit: commit 502ffb1f389011b28ee51815242c7397790802d5 Author: Andrew MacLeod Date: Tue Nov 2 21:26:44 2021 -0400 Switch vrp2 to ranger. This patch flips the default for the VRP2 pass to execute ranger vrp ra= ther than the assert_expr version of VRP. * params.opt (param_vrp2_mode): Make ranger the default for VRP= 2.=