[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20190306172608.GF13351@linux.ibm.com>
Date: Wed, 6 Mar 2019 09:26:08 -0800
From: "Paul E. McKenney" <paulmck@...ux.ibm.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Akira Yokosawa <akiyks@...il.com>, Borislav Petkov <bp@...en8.de>,
Andrea Parri <andrea.parri@...rulasolutions.com>,
linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org,
Alan Stern <stern@...land.harvard.edu>,
Will Deacon <will.deacon@....com>,
Boqun Feng <boqun.feng@...il.com>,
Nicholas Piggin <npiggin@...il.com>,
David Howells <dhowells@...hat.com>,
Jade Alglave <j.alglave@....ac.uk>,
Luc Maranget <luc.maranget@...ia.fr>,
Daniel Lustig <dlustig@...dia.com>
Subject: Re: [RFC PATCH] tools/memory-model: Remove (dep ; rfi) from ppo
On Wed, Mar 06, 2019 at 05:58:31PM +0100, Peter Zijlstra wrote:
> On Thu, Mar 07, 2019 at 12:46:05AM +0900, Akira Yokosawa wrote:
> > So, I'm looking at the macro RELOC_HIDE() defined in include/linux/compiler-gcc.h.
>
> > Am I the only one who was not aware of this gcc-specific macro?
>
> It's one I regularly see, but had forgotten about in this context.
>
> However; you can also fix things by adding asm volatile ("":::"memory");
> in places.
>
> But that's not really the point; I would really rather have a cmdline
> knob to fix things. That way we can compile the kernel with and without
> and look for differences. -fno-unicorns or something :-)
>
> While I understand some compiler people revel in UB and love to make
> unicorns happen, I think in this case the produces result is utterly
> insane.
Because I couldn't resist...
https://raphlinus.github.io/assets/Anything_is_Possible_scaled.jpg
Thanx, Paul
Powered by blists - more mailing lists