From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 9DA64382C411; Thu, 24 Jun 2021 21:18:08 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9DA64382C411 From: "msebor at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/101134] Bogus -Wstringop-overflow warning about non-existent overflow Date: Thu, 24 Jun 2021 21:18:08 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end X-Bugzilla-Version: 11.1.0 X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: normal X-Bugzilla-Who: msebor at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: rsandifo 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: Thu, 24 Jun 2021 21:18:08 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D101134 --- Comment #12 from Martin Sebor --- I don't need to be convinced that it would be nice to be able to differenti= ate between certain bugs and possible ones. The text of this class of warnings already does differentiate between "may write/read/access" and "writing/reading/accessing" under some conditions: https://gcc.gnu.org/git/?p=3Dgcc.git;a=3Dblob;f=3Dgcc/builtins.c;h=3D73c12e= 3bb8c39907b6bd95148f860709dbbf3f50;hb=3Drefs/heads/releases/gcc-11#l4136 This is not among them. In this case the IL that triggers the warning is: [local count: 10145877954]: # size_18 =3D PHI <512(2), size_13(10)> # prephitmp_54 =3D PHI <"edFunction.staticBuf(2), newBuf_36(10)> ... [local count: 2825037180]: newBuf_33 =3D malloc (_51); goto ; [100.00%] [local count: 6591753510]: newBuf_35 =3D realloc (_30, _51); ... [local count: 9416790700]: # newBuf_36 =3D PHI ... [local count: 3449598541]: MEM[(char *)prephitmp_54 + -1B] =3D 0; <<< -Wstring-overflow prephitmp_54 is set to point to either the beginning of quotedFunction.staticBuf or the dynamically allocated buffer. So prephitmp= _54 - 1 is unconditionally invalid and the warning triggers. The warning doesn= 't consider the predicates leading up to the invalid store: all it uses to make its decision is the statement itself and its arguments. For PHIs, to minim= ize noise, it triggers only if the statement is invalid for all arguments. Thi= s is how most flow-based warnings work in GCC (some like -Warray-bounds don't consider PHIs yet). To do better and either hope to issue a "maybe" kind of a warning or prefer= ably avoid it altogether if the code is unreachable we would need to do what -Wmaybe-uninitialized does (as I said in comment #5) and analyze the predicates. I've been working on extracting the uninitialized predicate analyzer for the last few months. I'm not sure to what extent it will be usable outside the uninitialized pass yet or how well it will work. As we know, -Wmaybe-uninitialized has lots of false positives (and negatives). B= ut even the uninitialized pass issues unconditional warnings for conditional b= ugs. For instance: int f (void) {=20 int i, j =3D 0; int *p =3D i ? &i : &j; return *p; } a.c: In function =E2=80=98f=E2=80=99: a.c:4:14: warning: =E2=80=98i=E2=80=99 is used uninitialized [-Wuninitializ= ed] 4 | int *p =3D i ? &i : &j; | ^ It does that because the first time it runs it's too early to make the distinction, and by the second time it runs to issuse -Wmaybe-uninitialized= the uninitialized read has been eliminated. And this is done to strike a reasonable balance between false negatives and positives. So in general, the distinction between the two cases can only be made when = it can be discerned from the IL, and the IL doesn't always preserve the conditional nature of the problem statement. So every warning must always = be viewed as a "maybe" kind of a warning. It will never be a sure a thing, ei= ther at the scope of individual functions, and certainly not with inlining or function cloning.=