[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4CCB2B7B.6020002@zytor.com>
Date: Fri, 29 Oct 2010 13:15:55 -0700
From: "H. Peter Anvin" <hpa@...or.com>
To: Steven Rostedt <rostedt@...dmis.org>
CC: David Daney <ddaney@...iumnetworks.com>,
Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>,
Ingo Molnar <mingo@...e.hu>, Jason Baron <jbaron@...hat.com>,
rth@...hat.com, tglx@...utronix.de, andi@...stfloor.org,
roland@...hat.com, masami.hiramatsu.pt@...achi.com,
fweisbec@...il.com, avi@...hat.com, davem@...emloft.net,
vgoyal@...hat.com, sam@...nborg.org, tony@...eyournoodle.com,
dsd@...top.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] jump label: disable due to compiler bug
On 10/29/2010 10:33 AM, Steven Rostedt wrote:
>>
>> Should this knowledge be builtin to the jump label enabling calculus?
>
> No, because we can't trust versions. We never know what home grown gcc a
> kernel developer is using (and what has been backported or not). Thus
> the only option is to have a builtin test we can do at compile time to
> determine if the bug exists or not and decide then.
>
> Note, I'm currently running my last set of patches through ktest. When
> it finishes (presumably with no issues), I'll post a pull request.
>
I disagree with that assessment.
We know that if version >= 4.5.2 the problem has been fixed, and that
for earlier versions we can't know if it's there, so just disable it for
gcc < 4.5.2. The fix might have been backported, but it's not a big
deal if the users of backported compilers don't see the full benefit --
it's only a problem during a limited time window anyway.
Admittedly it would be nice to have a header file or even a
configuration file where the gcc version is tested and workarounds are
centralized; then the backporters could put their own overrides in there.
-hpa
--
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