From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 777D9138334 for ; Fri, 14 Sep 2018 03:36:19 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 20827E0D89; Fri, 14 Sep 2018 03:36:16 +0000 (UTC) Received: from smtp.gentoo.org (dev.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 9F225E0D80 for ; Fri, 14 Sep 2018 03:36:15 +0000 (UTC) Received: from mail-it0-f52.google.com (mail-it0-f52.google.com [209.85.214.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mattst88) by smtp.gentoo.org (Postfix) with ESMTPSA id E55C6335CF2 for ; Fri, 14 Sep 2018 03:36:13 +0000 (UTC) Received: by mail-it0-f52.google.com with SMTP id 139-v6so843002itf.0 for ; Thu, 13 Sep 2018 20:36:13 -0700 (PDT) X-Gm-Message-State: APzg51CQ/9c39q0imRz6+3tpykkdlTllx1iHPDT25zAubRPgM0gEuhww hL4Sj+Uw5rHjXZ76STum9aH2BND063M32MuVBnc= X-Google-Smtp-Source: ANB0VdZSwx3iWZ0YPK0dRYWEuqwiQBdqEa/ZBfeA0MtrCTZ3X8jtZ19yJNb5znrBOUvhA8R4B+XwkSUAUQ+n32SZSRI= X-Received: by 2002:a24:6506:: with SMTP id u6-v6mr860498itb.130.1536896171904; Thu, 13 Sep 2018 20:36:11 -0700 (PDT) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 References: <20180909143221.21d784d02f51623e8c57c545@gentoo.org> <1536510660.863.9.camel@gentoo.org> <20180910074539.GA6512@baraddur.perfinion.com> <0d8b7f02-9c38-969c-413b-69d4dee6ca89@gentoo.org> <20180912085649.GA16516@baraddur.perfinion.com> <6c18c6bd-4cf3-dff6-2f20-c021063e01fa@gentoo.org> <20180913160347.GC26329@gentoo.org> <4FCF42AC-6B48-40F6-8B98-79CF71789A6A@gentoo.org> <3A8A39E8-91DF-40B2-8958-F046FA58622B@gentoo.org> In-Reply-To: <3A8A39E8-91DF-40B2-8958-F046FA58622B@gentoo.org> From: Matt Turner Date: Thu, 13 Sep 2018 20:35:59 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [gentoo-dev] Changing policy about -Werror To: gentoo development Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Archives-Salt: bde63519-4b07-435d-b39a-013ac3a8e825 X-Archives-Hash: 57055ba983ad0e8c7e82646aa27b6f5d On Thu, Sep 13, 2018 at 5:44 PM Richard Yao wrote: > > On Sep 13, 2018, at 7:21 PM, Matt Turner wrote: > > > > On Thu, Sep 13, 2018 at 4:13 PM Richard Yao wrote: > >>> On Sep 13, 2018, at 12:03 PM, Fabian Groffen wro= te: > >>> > >>>> On 13-09-2018 07:36:09 -0400, Richard Yao wrote: > >>>> > >>>> > >>>>>> On Sep 12, 2018, at 6:55 PM, Thomas Deutschmann wrote: > >>>>>> > >>>>>> On 2018-09-12 16:50, Rich Freeman wrote: > >>>>>> There is also the case where we want these warnings to block > >>>>>> installation, because the risk of there being a problem is too gre= at. > >>>>> > >>>>> I really disagree with that. So many devs have already said multipl= e > >>>>> times in this thread that "-Werror" is only turning existing warnin= gs > >>>>> into fatal errors but "-Werror" itself doesn't add any new checks a= nd > >>>>> more often requires "-O3" to be useful. > >>>> The way that compilers work is that the warnings are generated in th= e front end while the optimization level affects the backend. That means th= at -O3 has no effect on the code that does error generation. This remark ab= out -O3 being needed to make -Werror useful is just plain wrong. > >>> > >>> Huh? -O3 enables more checks, which can generate more warnings. > >> > >> What checks are those? -O3 affects backend optimization while warnings= are generated by the front end. Once the immediate representation is gener= ated, there are no other warnings aside from those from the linker. > > > > https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html > > > > Search for "depend on" > > > > -> [...] estimated based on heuristics that depend on thelevel > > argument and on optimization > > > > -> Because these warnings depend on optimization [...] > > > > Yes, warnings are dependent on optimization level. > > There are three such options. The first two are for format statements: > > > =E2=80=9CWhen the exact number of bytes written by a format directive c= annot be determined at compile-time it is estimated based on heuristics tha= t depend on the level argument and on optimization. While enabling optimiza= tion will in most cases improve the accuracy of the warning, it may also re= sult in false positives. =E2=80=9C > > My read of this is that the warning occurs regardless of optimization lev= el, but it could somehow be improved by optimization. > > As for the last, it is for uninitialized variable reads. However, I think= you are misinterpreting the claim. The way that optimization level could a= ffect warning generation would be if the warning generation came after opti= mization passes that could hide reads. That means that -O3 would prevent th= e warning. > > This is a really odd design decision by the GCC developers. With other co= mpilers, the separation between front end and backend is strong enough that= you will never have this sort of thing. It does not seem necessary to me e= ither. :/ I'm sorry, but you really don't know what you're talking about. I've already told you once that you were just adding noise to this conversation.