From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id A0640385840D; Tue, 30 Jan 2024 08:00:30 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A0640385840D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1706601630; bh=OSRUDSB4Tch8JAFL/cVw5gM9CpnbT62RNOMBRWRNS+s=; h=From:To:Subject:Date:In-Reply-To:References:From; b=stFLiKQe8ry8mxCnL2O/01vepB15sK/eCr8jXniEGOfeN0YSh3eWNTnXj5IJnXUNa dJzu5rm9TpSnbn/r++iS3zCY7h0nqL82Q5crt7RA3L9Q1Bf8zR44kxZDiRVPAbkmaj JDnQi/cmkJ7/zGM5SjlkIXQRupURVfH0v/QUqckU= From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/113664] False positive warnings with -fno-strict-overflow (-Warray-bounds, -Wstringop-overflow) Date: Tue, 30 Jan 2024 08:00:30 +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: 14.0 X-Bugzilla-Keywords: diagnostic 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: cf_reconfirmed_on bug_status everconfirmed 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=3D113664 Richard Biener changed: What |Removed |Added ---------------------------------------------------------------------------- Last reconfirmed| |2024-01-30 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #4 from Richard Biener --- Confirmed. As usual it's jump-threading related where we isolate, in the -Warray-bounds case MEM[(char *)1B] =3D 48; we inline 'f' and then, when s =3D=3D dot =3D=3D NULL your code dereference= s both NULL and NULL + 1. So the diagnostic messages leave a lot to be desired but in the end they point to a problem in your code which is a guard against a NULL 's'. The jump threading is different with -fwrapv-pointer, in particular without it we just get the NULL dereference which we seem to ignore during array-bound diagnostics. We later isolate the paths as unreachable but that happens after the diagnostic.=