This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC][PATCH 0/5] arch: atomic rework
- From: Torvald Riegel <triegel at redhat dot com>
- To: Peter Zijlstra <peterz at infradead dot org>
- Cc: Will Deacon <will dot deacon at arm dot com>, "Paul E. McKenney" <paulmck at linux dot vnet dot ibm dot com>, Ramana Radhakrishnan <Ramana dot Radhakrishnan at arm dot com>, David Howells <dhowells at redhat dot com>, "linux-arch at vger dot kernel dot org" <linux-arch at vger dot kernel dot org>, "linux-kernel at vger dot kernel dot org" <linux-kernel at vger dot kernel dot org>, "torvalds at linux-foundation dot org" <torvalds at linux-foundation dot org>, "akpm at linux-foundation dot org" <akpm at linux-foundation dot org>, "mingo at kernel dot org" <mingo at kernel dot org>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Fri, 07 Feb 2014 19:43:22 +0100
- Subject: Re: [RFC][PATCH 0/5] arch: atomic rework
- Authentication-results: sourceware.org; auth=none
- References: <52F3DA85 dot 1060209 at arm dot com> <20140206185910 dot GE27276 at mudshark dot cambridge dot arm dot com> <20140206192743 dot GH4250 at linux dot vnet dot ibm dot com> <1391721423 dot 23421 dot 3898 dot camel at triegel dot csb> <20140206221117 dot GJ4250 at linux dot vnet dot ibm dot com> <1391730288 dot 23421 dot 4102 dot camel at triegel dot csb> <20140207042051 dot GL4250 at linux dot vnet dot ibm dot com> <20140207074405 dot GM5002 at laptop dot programming dot kicks-ass dot net> <20140207165028 dot GO4250 at linux dot vnet dot ibm dot com> <20140207165548 dot GR5976 at mudshark dot cambridge dot arm dot com> <20140207170654 dot GQ5002 at laptop dot programming dot kicks-ass dot net>
On Fri, 2014-02-07 at 18:06 +0100, Peter Zijlstra wrote:
> On Fri, Feb 07, 2014 at 04:55:48PM +0000, Will Deacon wrote:
> > Hi Paul,
> >
> > On Fri, Feb 07, 2014 at 04:50:28PM +0000, Paul E. McKenney wrote:
> > > On Fri, Feb 07, 2014 at 08:44:05AM +0100, Peter Zijlstra wrote:
> > > > On Thu, Feb 06, 2014 at 08:20:51PM -0800, Paul E. McKenney wrote:
> > > > > Hopefully some discussion of out-of-thin-air values as well.
> > > >
> > > > Yes, absolutely shoot store speculation in the head already. Then drive
> > > > a wooden stake through its hart.
> > > >
> > > > C11/C++11 should not be allowed to claim itself a memory model until that
> > > > is sorted.
> > >
> > > There actually is a proposal being put forward, but it might not make ARM
> > > and Power people happy because it involves adding a compare, a branch,
> > > and an ISB/isync after every relaxed load... Me, I agree with you,
> > > much preferring the no-store-speculation approach.
> >
> > Can you elaborate a bit on this please? We don't permit speculative stores
> > in the ARM architecture, so it seems counter-intuitive that GCC needs to
> > emit any additional instructions to prevent that from happening.
> >
> > Stores can, of course, be observed out-of-order but that's a lot more
> > reasonable :)
>
> This is more about the compiler speculating on stores; imagine:
>
> if (x)
> y = 1;
> else
> y = 2;
>
> The compiler is allowed to change that into:
>
> y = 2;
> if (x)
> y = 1;
If you write the example like that, this is indeed allowed because it's
all sequential code (and there's no volatiles in there, at least you
didn't show them :). A store to y would happen in either case. You
cannot observe the difference between both examples in a data-race-free
program.
Are there supposed to be atomic/non-sequential accesses in there? If
so, please update the example.
> Which is of course a big problem when you want to rely on the ordering.
>
> There's further problems where things like memset() can write outside
> the specified address range. Examples are memset() using single
> instructions to wipe entire cachelines and then 'restoring' the tail
> bit.
As Joseph said, this would be a bug IMO.
> While valid for single threaded, its a complete disaster for concurrent
> code.
>
> There's more, but it all boils down to doing stores you don't expect in
> a 'sane' concurrent environment and/or don't respect the control flow.
A few of those got fixed already, because they violated the memory
model's requirements. If you have further examples that are valid code
in the C11/C++11 model, please report them.