From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id BB5DA3858D20; Mon, 14 Mar 2022 19:04:23 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BB5DA3858D20 From: "amacleod at redhat dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/104746] False positive for -Wformat-overflow=2 since r12-7033-g3c9f762ad02f398c Date: Mon, 14 Mar 2022 19:04:23 +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: 12.0 X-Bugzilla-Keywords: diagnostic, lto X-Bugzilla-Severity: normal X-Bugzilla-Who: amacleod at redhat dot com X-Bugzilla-Status: REOPENED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 12.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: resolution bug_status 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: Mon, 14 Mar 2022 19:04:23 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D104746 Andrew Macleod changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|INVALID |--- Status|RESOLVED |REOPENED --- Comment #13 from Andrew Macleod --- Why can't we leave this open? There have been VRP bugs open since 2005. The= re was no intent to fix them back then, but they identify opportunities for improvement. I think this is a good placeholder for improvements in analyzing the parame= ters of the warning. We can make more effort when there is more than one paramet= er to see if the information can be further refined.=20=20 _4 =3D i_6(D) + j_7(D); if (_4 > 19) goto ; [INV] else goto ; [INV] : __builtin_sprintf (&a, "%u%u", i_6(D), j_7(D)); i_6 and j_7 are both understood to be [0,19], and it wouldn't take much more work to find if there is a relationship between them, and refine the values. They appear together in one statement _4 =3D i_6 + j_7, and _4 is known to = be [0,19] at the warning location.=20 so [0,19] =3D i_6 + j_7 we can ask what the range of i_6 or j_7 is if the other one is refined. [10,99] will create 2 characters of output, you can ask if i_6 is [10,19], whats the range of j_7, and it will give you [0,9]. And then the warning doesn't need to trigger. Likewise for i_6 computed from j_7 =3D [10, 19].=20 This could be generalized using [100,999] for 3 character outputs, [1000, 9= 999] is 4 characters, etc. And doing a bit more work trying to analyze the parameters. Those bits are all there now. This could be in the next release. I'd even argue we should probably split this into 2 reports. The earlier warning on: char *path =3D malloc(strlen(dirname) + strlen(result) + 2); sprintf(path, "%s/%s", dirname, result); Seems like a different opportunity in which we could track/associate strlen results with the string. ie result_17 =3D malloc (_5); sprintf (result_17, "%s", suffix_14); _6 =3D strlen (dirname_13); _7 =3D strlen (result_17); _8 =3D _6 + _7; _9 =3D _8 + 2; path_20 =3D malloc (_9); sprintf (path_20, "%s/%s", dirname_13, result_17); _6 is length of dirname_13, and _7 is length of result_17, Then we malloc = an object that is _6 + _7 + 2 and copy those 2 strings into it.=20 With the appropriate pointer/string/strlen/malloc associations it seems deterministically knowable that we can avoid that warning too. Any false positive we can potentially eliminate with some additional analys= is is worth tracking and considering IMO. This PR is on the list of PRs I tra= ck for possible future improvements.=