diff mbox

[1/2] MIPS: Kbuild: remove -Werror

Message ID 1335534510-12573-1-git-send-email-dedekind1@gmail.com
State New, archived
Headers show

Commit Message

Artem Bityutskiy April 27, 2012, 1:48 p.m. UTC
From: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>

MIPS build fails with the standard W=1 Kbuild switch with because of the
-Werror gcc switch.

This patch removes the gcc switch to make W=1 work. Mips is the only
architecture I know which does not build with W=1 and this upsets my aiaiai
scripts. And in general, you never know which warnings newer versions of gcc
will start emiting so having -Werror by default is not the best idea.

Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
---
 arch/mips/Kbuild |    5 -----
 1 files changed, 0 insertions(+), 5 deletions(-)

Comments

David Daney April 27, 2012, 5:03 p.m. UTC | #1
On 04/27/2012 06:48 AM, Artem Bityutskiy wrote:
> From: Artem Bityutskiy<artem.bityutskiy@linux.intel.com>
>
> MIPS build fails with the standard W=1 Kbuild switch with because of the
> -Werror gcc switch.
>
> This patch removes the gcc switch to make W=1 work. Mips is the only
> architecture I know which does not build with W=1 and this upsets my aiaiai
> scripts. And in general, you never know which warnings newer versions of gcc
> will start emiting so having -Werror by default is not the best idea.
>
> Signed-off-by: Artem Bityutskiy<artem.bityutskiy@linux.intel.com>

I think the warning messages are enough, we don't need to break things.

Acked-by: David Daney <david.daney@cavium.com>

> ---
>   arch/mips/Kbuild |    5 -----
>   1 files changed, 0 insertions(+), 5 deletions(-)
>
> diff --git a/arch/mips/Kbuild b/arch/mips/Kbuild
> index 7dd65cf..0d37730 100644
> --- a/arch/mips/Kbuild
> +++ b/arch/mips/Kbuild
> @@ -1,8 +1,3 @@
> -# Fail on warnings - also for files referenced in subdirs
> -# -Werror can be disabled for specific files using:
> -# CFLAGS_<file.o>  := -Wno-error
> -subdir-ccflags-y := -Werror
> -
>   # platform specific definitions
>   include arch/mips/Kbuild.platforms
>   obj-y := $(platform-y)
Maciej W. Rozycki May 6, 2012, 7:04 a.m. UTC | #2
On Fri, 27 Apr 2012, David Daney wrote:

> > MIPS build fails with the standard W=1 Kbuild switch with because of the
> > -Werror gcc switch.
> > 
> > This patch removes the gcc switch to make W=1 work. Mips is the only
> > architecture I know which does not build with W=1 and this upsets my aiaiai
> > scripts. And in general, you never know which warnings newer versions of gcc
> > will start emiting so having -Werror by default is not the best idea.
> > 
> > Signed-off-by: Artem Bityutskiy<artem.bityutskiy@linux.intel.com>
> 
> I think the warning messages are enough, we don't need to break things.

 I disagree.  People generally don't fix their broken code just because it 
triggers warnings.  The cases where GCC is genuinely confused are the 
minority -- and even if so, chances are the human reader of that code will 
also be.

  Maciej
Artem Bityutskiy May 6, 2012, 7:34 a.m. UTC | #3
On Sun, 2012-05-06 at 08:04 +0100, Maciej W. Rozycki wrote:
> On Fri, 27 Apr 2012, David Daney wrote:
> 
> > > MIPS build fails with the standard W=1 Kbuild switch with because of the
> > > -Werror gcc switch.
> > > 
> > > This patch removes the gcc switch to make W=1 work. Mips is the only
> > > architecture I know which does not build with W=1 and this upsets my aiaiai
> > > scripts. And in general, you never know which warnings newer versions of gcc
> > > will start emiting so having -Werror by default is not the best idea.
> > > 
> > > Signed-off-by: Artem Bityutskiy<artem.bityutskiy@linux.intel.com>
> > 
> > I think the warning messages are enough, we don't need to break things.
> 
>  I disagree.  People generally don't fix their broken code just because it 
> triggers warnings.  The cases where GCC is genuinely confused are the 
> minority -- and even if so, chances are the human reader of that code will 
> also be.

Aggressive opinion, nothing more. A patch which fixes the real issue a
better way would be way more respectful.
Maciej W. Rozycki May 6, 2012, 8:32 a.m. UTC | #4
On Sun, 6 May 2012, Artem Bityutskiy wrote:

> >  I disagree.  People generally don't fix their broken code just because it 
> > triggers warnings.  The cases where GCC is genuinely confused are the 
> > minority -- and even if so, chances are the human reader of that code will 
> > also be.
> 
> Aggressive opinion, nothing more. A patch which fixes the real issue a
> better way would be way more respectful.

 I didn't trigger the issue, so I have nothing to fix.  I would if it was 
me who did.

 And my opinion is based on experience.  Please check the LMO archives for 
why Ralf added this option in the first place -- many years ago.  It's 
probably recorded in the git repository too (I'm not sure if the option 
was added before or after we moved away from CVS, but in any case old 
change logs have been imported when our current repo was created).

  Maciej
Artem Bityutskiy May 6, 2012, 8:37 a.m. UTC | #5
On Sun, 2012-05-06 at 09:32 +0100, Maciej W. Rozycki wrote:
>  And my opinion is based on experience.  Please check the LMO archives for 
> why Ralf added this option in the first place -- many years ago.  It's 
> probably recorded in the git repository too (I'm not sure if the option 
> was added before or after we moved away from CVS, but in any case old 
> change logs have been imported when our current repo was created).

We need to figure out how to make -Werror be applied only when we do not
have W=[123].
Maciej W. Rozycki May 6, 2012, 9:14 a.m. UTC | #6
On Sun, 6 May 2012, Artem Bityutskiy wrote:

> >  And my opinion is based on experience.  Please check the LMO archives for 
> > why Ralf added this option in the first place -- many years ago.  It's 
> > probably recorded in the git repository too (I'm not sure if the option 
> > was added before or after we moved away from CVS, but in any case old 
> > change logs have been imported when our current repo was created).
> 
> We need to figure out how to make -Werror be applied only when we do not
> have W=[123].

 Hmm, that sounds better, however has the counter-intuitive side-effect of 
lowering the severity of the warnings that are enabled even without 
W=[123].

 Modern versions of GCC have that selective -Wno-error=foo option and I 
think it should be possible to build the precise list of warnings not to 
choke on locally in arch/mips/Kbuild with little Makefile magic, falling 
back to something sane for older GCC versions (I'm not sure exactly when 
these selective options were added, certainly sometime between 4.1 and 
4.3).

 This will be a bit imperfect if any of these additional -Wfoo options 
duplicate ones already added to KBUILD_CFLAGS in our top-level Makefile 
(either explicitly or via -Wall), but that's about the best we can do.  
I'll see if I can cook up something quickly.

  Maciej
Jonas Gorski May 13, 2012, 12:08 p.m. UTC | #7
Hi,
On 6 May 2012 11:14, Maciej W. Rozycki <macro@linux-mips.org> wrote:
> On Sun, 6 May 2012, Artem Bityutskiy wrote:
>
>> >  And my opinion is based on experience.  Please check the LMO archives for
>> > why Ralf added this option in the first place -- many years ago.  It's
>> > probably recorded in the git repository too (I'm not sure if the option
>> > was added before or after we moved away from CVS, but in any case old
>> > change logs have been imported when our current repo was created).
>>
>> We need to figure out how to make -Werror be applied only when we do not
>> have W=[123].
>
>  Hmm, that sounds better, however has the counter-intuitive side-effect of
> lowering the severity of the warnings that are enabled even without
> W=[123].
>
>  Modern versions of GCC have that selective -Wno-error=foo option and I
> think it should be possible to build the precise list of warnings not to
> choke on locally in arch/mips/Kbuild with little Makefile magic, falling
> back to something sane for older GCC versions (I'm not sure exactly when
> these selective options were added, certainly sometime between 4.1 and
> 4.3).
>
>  This will be a bit imperfect if any of these additional -Wfoo options
> duplicate ones already added to KBUILD_CFLAGS in our top-level Makefile
> (either explicitly or via -Wall), but that's about the best we can do.
> I'll see if I can cook up something quickly.

Hm, how about doing it the other way round, i.e. explicitly enable
which warnings we want to treat as errors with -Werror=foo? That way
we don't lower the severity when W=[123] and new default enabled
warnings in gcc can't break the build any more, just better (or worse
;-) heuristics can.


Jonas
diff mbox

Patch

diff --git a/arch/mips/Kbuild b/arch/mips/Kbuild
index 7dd65cf..0d37730 100644
--- a/arch/mips/Kbuild
+++ b/arch/mips/Kbuild
@@ -1,8 +1,3 @@ 
-# Fail on warnings - also for files referenced in subdirs
-# -Werror can be disabled for specific files using:
-# CFLAGS_<file.o> := -Wno-error
-subdir-ccflags-y := -Werror
-
 # platform specific definitions
 include arch/mips/Kbuild.platforms
 obj-y := $(platform-y)