Re: linux-next: build warning after merge of the char-misc tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Feb 15, 2013 at 9:05 PM, Arnd Bergmann <arnd@xxxxxxxx> wrote:
> On Friday 15 February 2013, Greg KH wrote:
>> On Fri, Feb 15, 2013 at 04:26:57PM +1100, Stephen Rothwell wrote:
>> >
>> > After merging the char-misc tree, today's linux-next build (x86_64
>> > allmodconfig) produced this warning:
>> >
>> > drivers/w1/slaves/w1_therm.c: In function 'w1_therm_read':
>> > drivers/w1/slaves/w1_therm.c:245:15: warning: 'crc' may be used uninitialized in this function [-Wuninitialized]
>> >
>> > Its a false positive, but it was introduced by commit 867ff9880d5d
>> > ("w1_therm: Retries: remove old code add CRC")
>>
>> I don't see that here with gcc 4.7.1, perhaps you need to upgrade your
>> version of gcc to not show these false positives?
>
> I have finally put the pieces of the puzzle together. I already knew
> that some of these warnings only happen when building with -Os (even
> in gcc-4.8), since gcc turns off the inlining at a point after it
> determines that the variable might be used uninitialized but before
> determining that it's actually isn't.
>
> I think the best way forward is to disable this particular warning
> when building with -Os (which is enabled in allyesconfig). A false
> positive seems more harmful than a false negative here, because it
> prompts people to add broken initializations. This patch indeed
> makes the majority of the allyesconfig warnings on ARM go away.
> For the regular defconfig builds, we are already mostly clean,
> and those are built with -O2.
>
> Signed-off-by: Arnd Bergmann <arnd@xxxxxxxx>
>
> diff --git a/Makefile b/Makefile
> index 0b4bf62..4d60d97 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-option,-Wno-maybe-uninitialized,)
>  else
>  KBUILD_CFLAGS  += -O2
>  endif

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".

Furthermore, "-Wno-maybe-uninitialized" gcc-option is available
gcc-4-7+, so your patch is incomplete.
Setting it is a "workaround" and a bit rough to stop compilation.
Here, I have it only activated for ltrace compilation.

I am attaching my ltrace.mk file for Freetz.

Greetings from Tuebingen to Tuebingen,
- Sedat -

[ ltrace.mk ]
...
# Set compiler options to suppress warnings treated as errors
# Reference: gcc manual chapter "3.8 Options to Request or Suppress Warnings"
# <http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#Warning-Options>
# EXAMPLE: TARGET_CC_OPTS := -Wno-error=maybe-uninitialized (here: gcc-4.7)
ifneq (,$(strip $(filter 4.7,$(TARGET_TOOLCHAIN_GCC_MAJOR_VERSION))))
TARGET_CC_OPTS := -Wno-error=maybe-uninitialized
else
TARGET_CC_OPTS :=
endif
...
- EOT -

Attachment: ltrace.mk
Description: Binary data


[Index of Archives]     [Linux Kernel]     [Linux USB Development]     [Yosemite News]     [Linux SCSI]

  Powered by Linux