[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 22 Nov 2013 01:39:04 +0100
From: Jakub Jelinek <jakub@...hat.com>
To: Luis Lozano <llozano@...gle.com>
Cc: Alexander Holler <holler@...oftware.de>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
Richard Henderson <rth@...ddle.net>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Will Deacon <will.deacon@....com>,
Catalin Marinas <catalin.marinas@....com>,
Peter Zijlstra <peterz@...radead.org>,
lttng-dev@...ts.lttng.org, Nathan Lynch <Nathan_Lynch@...tor.com>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Bhaskar Janakiraman <bjanakiraman@...omium.org>,
Han Shen <shenhan@...omium.org>
Subject: Re: current_thread_info() not respecting program order with gcc 4.8.x
On Thu, Nov 21, 2013 at 03:45:35PM -0800, Luis Lozano wrote:
> I think we need a reproducer. Without this we may all be going on the
> wrong path. This whole conversation started on an *assumption* that
> some accesses were being reordered.
>
> evidence of the reorder or reproducer please?
Yeah, if a compiler bug is suspected, can anybody please open
a bugreport in http://gcc.gnu.org/bugzilla/ with the preprocessed source,
compiler version, flags and how it was configured and some hint in which
function to look for what exactly? We don't necessarily need a runtime
small reproducer, but if it can be shown in the assembly what has been
reordered and why you think it shouldn't, with the above mentioned input
that ought to be sufficient. Thanks.
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