From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 2921E385EC56; Thu, 24 Jun 2021 22:18:30 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2921E385EC56 From: "dangelog at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/101134] Bogus -Wstringop-overflow warning about non-existent overflow Date: Thu, 24 Jun 2021 22:18:29 +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: dangelog at gmail dot com 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 22:18:30 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D101134 --- Comment #13 from Giuseppe D'Angelo --- Hi, (In reply to Martin Sebor from comment #12) > 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 thin= g, > either at the scope of individual functions, and certainly not with inlin= ing > or function cloning. I think there's been a misunderstanding. Apologies if I created confusion, = let me try and reset the conversation: I perfectly understand if, in the context of this particular warning (or any other similar middle-end warning), it is very hard, or currently impossible= , or even always impossible to distinguish between the "maybe" case and the "certain" case.=20 Without such a distinction available or possible, I'm also OK with raising= =20 false positives. Therefore, in relation to this aspect of the original submission (the code raising a false positive warning), I'm perfectly fine = at marking the request of not triggering the warning altogether as out of scop= e / won't fix / etc. On other hand, I was not OK with the idea that the *warning message* should keep saying that "there *is* an overflow", in a positive indicative mood. A= ll I'd really ask there would be to reword the message in order to say somethi= ng like "there *may be* an overflow" instead. It might seem like a trivial/use= less change for someone who knows how the middle-end works and where such warnin= gs come from, but it would bring a lot of clarity to end-users (to me, at leas= t) if any warning message would clearly indicate whether it may be a false positive. And that could be achieved by simply adding "may" to the warning messages in question. Does this make sense? Thanks,=