linux-next.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: sedat.dilek@gmail.com
Cc: Greg KH <greg@kroah.com>, Stephen Rothwell <sfr@canb.auug.org.au>,
	linux-next@vger.kernel.org, linux-kernel@vger.kernel.org,
	David Stevenson <david@avoncliff.com>
Subject: Re: linux-next: build warning after merge of the char-misc tree
Date: Fri, 1 Mar 2013 17:16:42 +0000	[thread overview]
Message-ID: <201303011716.43148.arnd@arndb.de> (raw)
In-Reply-To: <CA+icZUUCRb9DafSj0Vhtq68mNxBPHVpSkeau+UEkfVb3Jv0k6g@mail.gmail.com>

On Friday 01 March 2013, Sedat Dilek wrote:
> I have seen a lot of such failures when using the Freetz (a small
> router project) build-system with gcc-4.7-x where "-Os" is default
> optimization-level.
> 
> Last, when I tried to integrate ltrace GIT snapshots into Freetz.
> All these "build-errors" could be solved in changing ltrace code.
> So, I would not talk about "false positives".

But the point is that we should not be changing the source code to
unnecessary initializations, because that may hide real bugs if the
code is modified in a way that relies on a sane value of some
variable. They are false positives if the code is actually correct
and does not need to be changed.

I actually have a newer version of my patch (see below) that uses
the cc-disable-warning macro in order to avoid some of the
side-effects of setting an unknown option on older gcc versions.

> Furthermore, "-Wno-maybe-uninitialized" gcc-option is available
> gcc-4-7+, so your patch is incomplete.

O don't understand. The patch avoids the warnings when building
with gcc-4.7 or higher with -Os. 

	Arnd


>From d313219a2f2e0753b8e96105b7a944e1c22566ae Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd@arndb.de>
Date: Fri, 15 Feb 2013 21:23:58 +0100
Subject: [PATCH] Turn off -Wmaybe-uninitialized when building with -Os

gcc-4.7 and higher add a lot of false positive warnings about
potential uses of uninitialized warnings, but only when optimizing
for size (-Os). This is the default when building allyesconfig,
which turns on CONFIG_CC_OPTIMIZE_FOR_SIZE.

In order to avoid getting a lot of patches that initialize such
variables and accidentally hide real errors along the way, let's
just turn off this warning on the respective gcc versions
when building with size optimizations. The -Wmaybe-uninitialized
option was introduced in the same gcc version (4.7) that is now
causing the false positives, so there is no effect on older compilers.

A side effect is that when building with CONFIG_CC_OPTIMIZE_FOR_SIZE,
we might now see /fewer/ warnings about possibly uninitialized
warnings than with -O2, but that is still much better than seeing
warnings known to be bogus.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>

diff --git a/Makefile b/Makefile
index 473beb1..f0ec9bc 100644
--- a/Makefile
+++ b/Makefile
@@ -570,7 +570,7 @@ endif # $(dot-config)
 all: vmlinux
 
 ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE
-KBUILD_CFLAGS	+= -Os
+KBUILD_CFLAGS	+= -Os $(call cc-disable-warning,maybe-uninitialized,)
 else
 KBUILD_CFLAGS	+= -O2
 endif

  reply	other threads:[~2013-03-01 17:17 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-15  5:26 linux-next: build warning after merge of the char-misc tree Stephen Rothwell
2013-02-15 17:34 ` Greg KH
2013-02-15 18:07   ` Arnd Bergmann
2013-02-15 20:05   ` Arnd Bergmann
2013-03-01 15:51     ` Sedat Dilek
2013-03-01 17:16       ` Arnd Bergmann [this message]
2013-03-01 17:43         ` Sedat Dilek
2015-03-27  7:48 Stephen Rothwell
2015-03-31 19:35 ` Fabian Frederick
2015-04-03 14:05   ` Greg KH
2017-03-28  3:31 Stephen Rothwell
2017-03-28  3:58 ` Masahiro Yamada
2017-07-20  4:12 Stephen Rothwell
2017-07-20  5:13 ` Greg KH
2017-07-20 14:52   ` KY Srinivasan
2017-07-20  9:14 ` Greg KH
2017-12-12  3:39 Stephen Rothwell
2017-12-12 11:49 ` Greg KH
2018-10-02  5:31 Stephen Rothwell
2018-10-02  8:34 ` Bartosz Golaszewski
2018-10-02  9:12 Stephen Rothwell
2018-10-02  9:49 ` Bartosz Golaszewski
2018-10-02  9:56   ` Srinivas Kandagatla
2018-10-02 10:04     ` Bartosz Golaszewski
2019-04-26  5:56 Stephen Rothwell
2019-04-26  6:25 ` Greg KH
2019-04-26 14:30   ` Patrick Venture
2019-04-26 18:00     ` Patrick Venture
2020-05-01  6:28 Stephen Rothwell
2020-05-01  6:55 ` Greg KH
2020-05-01 10:17   ` Rajan Vaja
2021-01-29  7:07 Stephen Rothwell
2021-04-06 11:44 Stephen Rothwell
2021-04-06 11:46 ` Stephen Rothwell
2021-04-06 14:07 ` Greg KH
2021-04-06 14:13   ` Gustavo Pimentel
2021-04-06 14:15     ` Greg KH
2021-04-06 17:28       ` Gustavo Pimentel
2021-04-06 17:33         ` Greg KH
2021-05-24  6:19 Stephen Rothwell
2022-07-15 11:43 Stephen Rothwell
2024-04-15  5:22 Stephen Rothwell
2024-04-15  7:21 ` Greg KH

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=201303011716.43148.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=david@avoncliff.com \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=sedat.dilek@gmail.com \
    --cc=sfr@canb.auug.org.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).