All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brian Norris <computersforpeace@gmail.com>
To: Daniel Axtens <dja@axtens.net>
Cc: Arnd Bergmann <arnd@arndb.de>,
	linuxppc-dev@lists.ozlabs.org,
	Michael Ellerman <mpe@ellerman.id.au>,
	Michael Neuling <mikey@neuling.org>,
	Anton Blanchard <anton@au1.ibm.com>,
	linux-kernel@vger.kernel.org, Michal Marek <mmarek@suse.com>,
	Ian Munsie <imunsie@au1.ibm.com>
Subject: Re: Build failure: -Wno-unused-const-variable DNE on old GCC
Date: Thu, 7 Jan 2016 15:02:25 -0800	[thread overview]
Message-ID: <20160107230225.GA126548@google.com> (raw)
In-Reply-To: <87oacx6m14.fsf@gamma.ozlabs.ibm.com>

On Fri, Jan 08, 2016 at 09:51:35AM +1100, Daniel Axtens wrote:
> 
> > Alternatively, remove the -Werror. We occasionally get people that add this
> > flag to a Makefile, but it tends to cause more trouble whenever a new
> > gcc version arrives.

^^ Your reasons below don't really address this point. No matter how
well you patch a later kernel release, you can't fix a problem in an
existing kernel release that is triggered by a new warning in a new
compiler. This shouldn't cause a build failure.

> Speaking up as the person who added -Werror to cxl, I'd really rather
> it stayed. There are a number of reasons I think this. Here's the first
> three that came to mind.
> 
>  - cxl is powerpc specific (and always will be for deep seated hardware
>    reasons), and is handled through the powerpc tree. arch/powerpc
>    compiles with -Werror, and as part of the powerpc ecosystem, cxl
>    should too.
> 
>  - It forces cxl developers to a higher standard. cxl has already had
>    more than it's fair share of incredibly difficult to debug issues,
>    so any way we can reduce the risk of errors going in makes our lives
>    (and our end-users lives) better.

One problem with this point: not all warnings are under the purview of
cxl developers. For instance, if I turn up warning verbosity (W=1), then
the *header* files start producing plenty of warnings. Should this break
the build? Your code didn't change, and you can't fix those errors.

That is a real use case for me daily: I turn the warning verbosity up on
my compile tests, then (smart)diff the build logs before and after
new patches. That way, I can see what new warnings (even potentially
false positive ones) are introduced. I can't do that if every random
developer wants to stick -Werror in their Makefile.

>  - I am (and I'm quite confident the other cxl people are) quite happy to
>    send patches to fix build-breaking issues such as this. Indeed, I
>    would have, except you sent it during the Australian night :)
> 
> If it's really super-duper important we can consider putting it behind a
> config guard, but I'd really rather not.

I think there are plenty of reasons to either remove -Werror, or make it
configurable. Some of them are detailed above.

Maybe you can gate the -Werror on CONFIG_PPC_WERROR, just like the rest
of PowerPC?

Brian

  reply	other threads:[~2016-01-07 23:02 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-07 18:54 Build failure: -Wno-unused-const-variable DNE on old GCC Brian Norris
2016-01-07 19:37 ` Joe Perches
2016-01-07 19:44   ` Michal Marek
2016-01-07 19:57     ` Joe Perches
2016-01-07 20:18       ` Brian Norris
2016-01-07 20:38         ` [PATCH] misc: cxl: fix build for GCC 4.6.x Brian Norris
2016-01-08  2:12           ` Michael Ellerman
2016-01-30 14:20         ` Build failure: -Wno-unused-const-variable DNE on old GCC Maciej W. Rozycki
2016-01-30 17:37           ` Joe Perches
2016-01-07 20:25 ` Arnd Bergmann
2016-01-07 22:51   ` Daniel Axtens
2016-01-07 23:02     ` Brian Norris [this message]
2016-01-08  1:31       ` Ian Munsie
2016-01-08  2:07         ` Brian Norris
2016-01-08  2:16           ` Michael Ellerman
2016-01-08 10:14             ` David Laight
2016-01-08 10:14               ` David Laight
2016-01-08  1:33   ` Ian Munsie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160107230225.GA126548@google.com \
    --to=computersforpeace@gmail.com \
    --cc=anton@au1.ibm.com \
    --cc=arnd@arndb.de \
    --cc=dja@axtens.net \
    --cc=imunsie@au1.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mikey@neuling.org \
    --cc=mmarek@suse.com \
    --cc=mpe@ellerman.id.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.