From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 73957 invoked by alias); 28 Oct 2016 13:18:11 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 73932 invoked by uid 89); 28 Oct 2016 13:18:10 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 spammy=Hx-languages-length:1767, late X-HELO: mail-qk0-f175.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=Uj43km1KSb/cE2XLvUkJbNrrxu7caBgEWlP3QfgwfbE=; b=ITsJdU+UASSns0+z5Xz7nU5D8Rlt6ZzkoLaApmEzCnZ97l6in5jCPDjafJXcELZfU3 Wl/v/Pf2R4DtbG20XIBPjZRP0aDp/uvQRBgRb95zNM/Z3LyQv1fCeXFuNs/Sw3ewiQxi oBCDobpafGOLcvWVAXdfL5FeelmthZn4XTVZL0DL0PKOFsZYh1/U42Pj0ieS+Hb+Uo0M tyU4YZPZiEW+8w1+xWQ6uW9W0vhUfPZ0zINKzf+3W8eOTKNk+mG2nJmVLgES76FBN3dT EegeBi/YaEKho3YtL3tk67EarXTzde6UCp2USGPoO5CA7/6egyDo7uPXRNOstO14JvTT PRkw== X-Gm-Message-State: ABUngveSdFWLfmIgo7JCxcGogSC9nho/MOe5FBAg8qGVjNknA8bKGeA+I5kM+cSJT+Rf9BjD X-Received: by 10.55.126.130 with SMTP id z124mr12529130qkc.63.1477660687789; Fri, 28 Oct 2016 06:18:07 -0700 (PDT) Subject: Re: [PATCH] Fix -Os related -Werror failures. To: Florian Weimer , Joseph Myers References: <6eac682f-26fa-6a47-9497-357206266ba1@redhat.com> <6be7dce5-bfa7-32c7-5bac-6c3b79776683@redhat.com> <38a493b5-e73f-1bf8-46f0-4121e547a05d@redhat.com> Cc: GNU C Library From: Carlos O'Donell Message-ID: <2ff34c0c-7571-4198-890a-2b30dd7d2920@redhat.com> Date: Fri, 28 Oct 2016 13:18:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <38a493b5-e73f-1bf8-46f0-4121e547a05d@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-10/txt/msg00532.txt.bz2 On 10/28/2016 08:55 AM, Florian Weimer wrote: > On 10/28/2016 02:49 PM, Joseph Myers wrote: >> On Fri, 28 Oct 2016, Florian Weimer wrote: >> >>> Those who want to build with -Os or other special compiler flags >>> should just configure with --disable-werror. We can't account >>> for every optimization someone might want to disable in their >>> build. >> >> I don't think --disable-werror should be encouraged. > > -Wmaybe-uninitialized warnings can be issued very late from the > optimizers, so this is very much a corner case in terms of usefulness > for -Werror because it is practically guaranteed to have new false > positives with unusual architectures, compiler versions, and > optimization flags. > > If the presence of this warning in particular leads people to use > --disable-werror, maybe we should remove it from the default set of > warnings which trigger errors. Remove -Wmaybe-uninitialized? That destroys some of the value of the warning and means we don't interact with upstream gcc to make it better, either during initial review or reviews when the gcc version gets new enough that we audit the diagnostic. I would rather follow Joseph's suggestion of adding optimization specific DIAG_* macros. e.g. DIAG_IGNORE_O3_NEEDS_COMMENT DIAG_IGNORE_O2_NEEDS_COMMENT DIAG_IGNORE_O1_NEEDS_COMMENT DIAG_IGNORE_Os_NEEDS_COMMENT DIAG_IGNORE_Og_NEEDS_COMMENT Where the diagnostic is only ignored for the relevant optimization mode. This way the patch I just suggested would use the *_Os_* variants and not interfere with -O2 builds. Since the kinds of warnings generated are rather tightly coupled with the optimization passes that are enabled, it makes sense to specialize them a bit. -- Cheers, Carlos.