From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by sourceware.org (Postfix) with ESMTP id 59D8F3857C7A for ; Tue, 1 Feb 2022 14:43:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 59D8F3857C7A Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=kernel.crashing.org Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 211EgeKc026602; Tue, 1 Feb 2022 08:42:40 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 211EgeKv026601; Tue, 1 Feb 2022 08:42:40 -0600 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Tue, 1 Feb 2022 08:42:39 -0600 From: Segher Boessenkool To: Martin Sebor via Gcc-help , Dumitru Ceara , Martin Sebor , richard.sandiford@arm.com Subject: Re: Potentially false-positive -Wstringop-overflow= warning with gcc >= 11.1 Message-ID: <20220201144239.GT614@gate.crashing.org> References: <8d42151f-7be2-4d67-5b46-a83ba55d5c1c@redhat.com> <20220128152748.GD614@gate.crashing.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, KAM_NUMSUBJECT, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-help@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-help mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2022 14:43:44 -0000 On Tue, Feb 01, 2022 at 05:18:57AM +0000, Richard Sandiford wrote: > I agree that changing the wording doesn't solve the whole problem, > but I think it does solve something. At the moment, we're effectively > asking each individual user to be aware of the context above, to know what > meaning is being attached to the present tense. Making the message more > equivocal would at least suggest that the compiler doesn't “know”. The compiler *does* know (in this case), but only for one internal copy of the code. The warning message (which could be an error in this case, the code replaced with a trap: a dest or source that does not point at an object is undefined behaviour, for memcpy). But the error message suggests that this happens on *every* execution of the memcpy. Which is wrong, misleading, the cause of all the confusion here. > It's not the pass's “fault” that it can't tell how closely the IL > it sees matches the original code. But it is GCC's “fault” as a whole, > not the user's, and I think that's what matters here. Yeah. > > What I think is needed here is to mention the conditions > > under which the invalid statement is executed. With that, we should > > be able to print the same context as what the static analyzer prints: > I agree this would be better, but I don't think it should hold back > tweaks to the error messages in the meantime. (And if the tracing > was an optional feature, we'd still want wording that makes sense > when the feature is turned off.) Exactly. It shouldn't be all that hard to steer the user towards discovering what is wrong with his code, instead of causing the user to think GCC is wrong again. > I realise this is rehashing an old discussion, sorry. But it seems > like it's a discussion that gets rehashed precisely because it's > about an issue that users keep hitting. Agreed, this needs to be fixed. The bigger issue is communication, the way diagnostic messages are phrased, not the analysis itself :-) Segher