[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <874kn1x7za.fsf@mid.deneb.enyo.de>
Date: Sun, 11 Oct 2020 14:28:09 +0200
From: Florian Weimer <fw@...eb.enyo.de>
To: Mark Wielaard <mark@...mp.org>
Cc: Andi Kleen <andi@...stfloor.org>,
Peter Zijlstra <peterz@...radead.org>,
Stephane Eranian <eranian@...gle.com>,
linux-toolchains@...r.kernel.org,
Arnaldo Carvalho de Melo <acme@...nel.org>,
linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...nel.org>,
Jiri Olsa <jolsa@...nel.org>,
Namhyung Kim <namhyung@...nel.org>,
Ian Rogers <irogers@...gle.com>,
"Phillips\, Kim" <kim.phillips@....com>,
Mark Rutland <mark.rutland@....com>,
Masami Hiramatsu <mhiramat@...nel.org>
Subject: Re: Additional debug info to aid cacheline analysis
* Mark Wielaard:
> On Sun, Oct 11, 2020 at 02:15:18PM +0200, Florian Weimer wrote:
>> * Mark Wielaard:
>>
>> > Yes, that would work. I don't know what the lowest supported GCC
>> > version is, but technically it was definitely fixed in 4.10.0, 4.8.4
>> > and 4.9.2. And various distros would probably have backported the
>> > fix. But checking for 5.0+ would certainly give you a good version.
>> >
>> > How about the attached?
>>
>> Would it be possible to test for the actual presence of the bug, using
>> -fcompare-debug?
>
> Yes, that was discussed in the original commit message, but it was decided
> that disabling it unconditionaly was easier. See commit 2062afb4f.
I think the short test case was not yet available at the time of the
Linux commit. But then it may not actually detect the bug in all
affected compilers.
Anyway, making this conditional on the GCC version is already a clear
improvement.
Powered by blists - more mailing lists