[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87h7r1x8kp.fsf@mid.deneb.enyo.de>
Date: Sun, 11 Oct 2020 14:15:18 +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:
> 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?
(But it seems to me that the treatment of this particular compiler bug
is an outlier: other equally tricky bugs do not receive this kind of
attention.)
Powered by blists - more mailing lists