[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFwq72kDdRSWXKhyO1j=_PAKB960+RNOD6Cou0wZTa+5Hw@mail.gmail.com>
Date: Tue, 5 Aug 2014 15:36:39 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: "Frank Ch. Eigler" <fche@...hat.com>
Cc: Josh Boyer <jwboyer@...oraproject.org>,
Jakub Jelinek <jakub@...hat.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
stable <stable@...r.kernel.org>,
Michel Dänzer <michel@...nzer.net>,
Markus Trippelsdorf <markus@...ppelsdorf.de>,
Josh Stone <jistone@...hat.com>
Subject: Re: [PATCH 3.15 33/37] Fix gcc-4.9.0 miscompilation of load_balance()
in scheduler
On Tue, Aug 5, 2014 at 2:07 PM, Frank Ch. Eigler <fche@...hat.com> wrote:
>
> Actually, "perf probe" does (via HAVE_DWARF_SUPPORT), to place probes
> and to extract variables at those probes, much as systemtap does.
> Without var-tracking, probes placed at most interior points of
> functions will make variables inaccessible.
.. and as mentioned, -O2 already does that for many things, even
*with* tracking.
In other words, anybody who relies on it has already learnt to work
around it. Or, more likely, there just isn't anybody who relies on it.
I don't understand how you guys can be so cavalier about a compiler
bug that has already resulted in actual real problems. You bring up
theoretical cases that nobody has actually reported, and are
apparently ignoring the fact that the compiler generates INCORRECT
CODE. So on one hand we have known breakage, on the other we have
theoretical "I can make an example" arguments of behavior that no sane
user has ever done.
Do you compile without -O2 too? Because I *guarantee* you that with
-O2 (even with tracking), you'll get "local variable 'xyz' optimized
away" cases.
Christ.
I have asked the compiler people at least twice whether there is some
way to limit it to just gcc-4.9.0/1, but the compiler people didn't
step up and say that it was safe.
In the meantime, crazy people can choose to compile with known-broken
compilers. Until you can get the compiler people to have some sane way
to know the problem is gone, I'm not going to maintain a kernel that
uses a known-broken compiler feature. It's that simple.
Linus
--
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