[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140730065312.GA1652@laptop.redhat.com>
Date: Wed, 30 Jul 2014 08:53:12 +0200
From: Jakub Jelinek <jakub@...hat.com>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: linux-kernel@...r.kernel.org, stable@...r.kernel.org,
Michel Dänzer <michel@...nzer.net>,
Markus Trippelsdorf <markus@...ppelsdorf.de>,
Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH 3.15 33/37] Fix gcc-4.9.0 miscompilation of
load_balance() in scheduler
On Tue, Jul 29, 2014 at 06:49:09PM -0700, Greg Kroah-Hartman wrote:
> 3.15-stable review patch. If anyone has any objections, please let me know.
IMNSHO this is a too big hammer approach. The bug happened on a single
file only (right?), so if anything, IMHO it could be disabled for that
single file only, and better do it only for compilers with the bug.
If there are wrong code bugs with -O2 (we've fixed many in the past), you
also don't turn off -O2 everywhere, similarly for -Os or any other options.
Disabling it just in case the same bug happens elsewhere when it actually
took 5 years before the bug caused miscompilation of something is too
defensive. We had at least 15 other wrong-code bugfixes just in between
4.9.0 and 4.9.1. -fvar-tracking-assignments doesn't make a small difference
in debug info, but significant for optimized code.
If you build the kernel without and with -fno-var-tracking-assignments,
you can use e.g. the dwlocstat tool to see what kind of difference it makes
for the kernel in particular in variable debug info coverage.
>
> --- a/Makefile
> +++ b/Makefile
> @@ -669,6 +669,8 @@ KBUILD_CFLAGS += -fomit-frame-pointer
> endif
> endif
>
> +KBUILD_CFLAGS += $(call cc-option, -fno-var-tracking-assignments)
> +
> ifdef CONFIG_DEBUG_INFO
> KBUILD_CFLAGS += -g
> KBUILD_AFLAGS += -Wa,--gdwarf-2
>
Jakub
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists