From: <gregkh@linuxfoundation.org>
To: torvalds@linux-foundation.org, gregkh@linuxfoundation.org
Cc: <stable@vger.kernel.org>, <stable-commits@vger.kernel.org>
Subject: Patch "Disable "maybe-uninitialized" warning globally" has been added to the 4.7-stable tree
Date: Mon, 26 Sep 2016 11:48:21 +0200 [thread overview]
Message-ID: <147488330114124@kroah.com> (raw)
This is a note to let you know that I've just added the patch titled
Disable "maybe-uninitialized" warning globally
to the 4.7-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
disable-maybe-uninitialized-warning-globally.patch
and it can be found in the queue-4.7 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 6e8d666e925333c55378e8d5540a8a9ee0eea9c5 Mon Sep 17 00:00:00 2001
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Wed, 27 Jul 2016 13:17:41 -0700
Subject: Disable "maybe-uninitialized" warning globally
From: Linus Torvalds <torvalds@linux-foundation.org>
commit 6e8d666e925333c55378e8d5540a8a9ee0eea9c5 upstream.
Several build configurations had already disabled this warning because
it generates a lot of false positives. But some had not, and it was
still enabled for "allmodconfig" builds, for example.
Looking at the warnings produced, every single one I looked at was a
false positive, and the warnings are frequent enough (and big enough)
that they can easily hide real problems that you don't notice in the
noise generated by -Wmaybe-uninitialized.
The warning is good in theory, but this is a classic case of a warning
that causes more problems than the warning can solve.
If gcc gets better at avoiding false positives, we may be able to
re-enable this warning. But as is, we're better off without it, and I
want to be able to see the *real* warnings.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
Makefile | 7 ++++---
arch/arc/Makefile | 4 +---
scripts/Makefile.ubsan | 4 ----
3 files changed, 5 insertions(+), 10 deletions(-)
--- a/Makefile
+++ b/Makefile
@@ -370,7 +370,7 @@ LDFLAGS_MODULE =
CFLAGS_KERNEL =
AFLAGS_KERNEL =
LDFLAGS_vmlinux =
-CFLAGS_GCOV = -fprofile-arcs -ftest-coverage -fno-tree-loop-im -Wno-maybe-uninitialized
+CFLAGS_GCOV = -fprofile-arcs -ftest-coverage -fno-tree-loop-im
CFLAGS_KCOV = -fsanitize-coverage=trace-pc
@@ -619,12 +619,13 @@ ARCH_CFLAGS :=
include arch/$(SRCARCH)/Makefile
KBUILD_CFLAGS += $(call cc-option,-fno-delete-null-pointer-checks,)
+KBUILD_CFLAGS += $(call cc-disable-warning,maybe-uninitialized,)
ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE
-KBUILD_CFLAGS += -Os $(call cc-disable-warning,maybe-uninitialized,)
+KBUILD_CFLAGS += -Os
else
ifdef CONFIG_PROFILE_ALL_BRANCHES
-KBUILD_CFLAGS += -O2 $(call cc-disable-warning,maybe-uninitialized,)
+KBUILD_CFLAGS += -O2
else
KBUILD_CFLAGS += -O2
endif
--- a/arch/arc/Makefile
+++ b/arch/arc/Makefile
@@ -74,9 +74,7 @@ endif
ifndef CONFIG_CC_OPTIMIZE_FOR_SIZE
# Generic build system uses -O2, we want -O3
# Note: No need to add to cflags-y as that happens anyways
-#
-# Disable the false maybe-uninitialized warings gcc spits out at -O3
-ARCH_CFLAGS += -O3 $(call cc-disable-warning,maybe-uninitialized,)
+ARCH_CFLAGS += -O3
endif
# small data is default for elf32 tool-chain. If not usable, disable it
--- a/scripts/Makefile.ubsan
+++ b/scripts/Makefile.ubsan
@@ -14,8 +14,4 @@ ifdef CONFIG_UBSAN
ifdef CONFIG_UBSAN_ALIGNMENT
CFLAGS_UBSAN += $(call cc-option, -fsanitize=alignment)
endif
-
- # -fsanitize=* options makes GCC less smart than usual and
- # increase number of 'maybe-uninitialized false-positives
- CFLAGS_UBSAN += $(call cc-option, -Wno-maybe-uninitialized)
endif
Patches currently in stable-queue which might be from torvalds@linux-foundation.org are
queue-4.7/disable-maybe-uninitialized-warning-globally.patch
queue-4.7/makefile-mute-warning-for-__builtin_return_address-0-for-tracing-only.patch
queue-4.7/ocfs2-fix-start-offset-to-ocfs2_zero_range_for_truncate.patch
queue-4.7/autofs-use-dentry-flags-to-block-walks-during-expire.patch
queue-4.7/disable-frame-address-warning.patch
queue-4.7/ocfs2-dlm-fix-race-between-convert-and-migration.patch
queue-4.7/revert-ocfs2-bump-up-o2cb-network-protocol-version.patch
queue-4.7/reiserfs-fix-new_insert_key-may-be-used-uninitialized.patch
reply other threads:[~2016-09-26 9:48 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=147488330114124@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=stable-commits@vger.kernel.org \
--cc=stable@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/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.