From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 40388 invoked by alias); 16 Dec 2019 14:46:07 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 40380 invoked by uid 89); 16 Dec 2019 14:46:06 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-7.9 required=5.0 tests=AWL,BAYES_00,KAM_SHORT,SPF_PASS autolearn=ham version=3.3.1 spammy=ultimately, Experience, Wuninitialized, wuninitialized X-HELO: mx2.suse.de Received: from mx2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 16 Dec 2019 14:46:01 +0000 X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Cc" Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 9FF9AAD0F; Mon, 16 Dec 2019 14:45:58 +0000 (UTC) From: Martin Jambor To: law@redhat.com, Michael Witten , Marc Glisse Cc: gcc-patches@gcc.gnu.org Cc: Subject: Re: Move -Wmaybe-uninitialized to -Wextra In-Reply-To: <3889a56a8dffe98f8fbfe6af9e0480c0bb1b1c9c.camel@redhat.com> References: <3889a56a8dffe98f8fbfe6af9e0480c0bb1b1c9c.camel@redhat.com> User-Agent: Notmuch/0.29.2 (https://notmuchmail.org) Emacs/26.3 (x86_64-suse-linux-gnu) Date: Mon, 16 Dec 2019 15:59:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2019-12/txt/msg01126.txt.bz2 Hi Jeff, On Sat, Dec 07 2019, Jeff Law wrote: > [...] > The whole point behind the uninitialized warning is to capture cases > where objects may not be properly initialized. For modern code the > simple cases typically "just work". What is by far the most > interesting cases are those with complex flow control, often > interacting with inline functions, address-of stripping, etc. These > are precisely the cases that humans aren't particularly good at > catching and having the compiler analyze those paths and issue warnings > that humans fix ultimately results in better quality code. Or "fixes" like: https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/expmed.c?r1=277864&r2=277863&pathrev=277864 if even we cannot deal with the false positive in our own compiler, how can we expect our users to do so? > > Experience has shown that if you put something in -Wall, people will > pay attention to it, and that is good for the long term quality of code > bases. If the diagnostic is outside of -Wall, it's largely ignored. I > think the pain of dealing with the Wuninitialized warts is smaller than > the pain of allowing these errors to persist. I'm afraid I that -Wmaybe-uninitialized is getting out of hand. I bet that some users regularly get these warnings coming from c++ header "libraries" (like they sometimes come out our vec.h which recently "broke" bootstrap) which they sometimes even cannot change and they then conclude that our -Wall is "unusable" and stop paying attention to all warnings. Martin