On Mon, Feb 10, 2014 at 01:27:51AM +0100, Torvald Riegel wrote:
On Fri, 2014-02-07 at 10:02 -0800, Paul E. McKenney wrote:
On Fri, Feb 07, 2014 at 04:55:48PM +, Will Deacon wrote:
[ . . . ]
And then it is a short and uncontroversial step to the following:
Initial state: x == y == 0
On Mon, Feb 10, 2014 at 01:06:48AM +0100, Torvald Riegel wrote:
On Thu, 2014-02-06 at 20:20 -0800, Paul E. McKenney wrote:
On Fri, Feb 07, 2014 at 12:44:48AM +0100, Torvald Riegel wrote:
On Thu, 2014-02-06 at 14:11 -0800, Paul E. McKenney wrote:
On Thu, Feb 06, 2014 at 10:17:03PM +0100,
On Fri, 2014-02-07 at 08:50 -0800, 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
On Fri, 2014-02-07 at 18:06 +0100, Peter Zijlstra wrote:
> On Fri, Feb 07, 2014 at 04:55:48PM +, Will Deacon wrote:
> > Hi Paul,
> >
> > On Fri, Feb 07, 2014 at 04:50:28PM +, Paul E. McKenney wrote:
> > > On Fri, Feb 07, 2014 at 08:44:05AM +0100, Peter Zijlstra wrote:
> > > > On Thu, Feb
On Fri, Feb 07, 2014 at 05:13:36PM +, Will Deacon wrote:
> On Fri, Feb 07, 2014 at 05:06:54PM +, Peter Zijlstra wrote:
> > On Fri, Feb 07, 2014 at 04:55:48PM +, Will Deacon wrote:
> > > Hi Paul,
> > >
> > > On Fri, Feb 07, 2014 at 04:50:28PM +, Paul E. McKenney wrote:
> > > > On
On Fri, Feb 07, 2014 at 04:55:48PM +, Will Deacon wrote:
> Hi Paul,
>
> On Fri, Feb 07, 2014 at 04:50:28PM +, 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:
> > > >
On Fri, 7 Feb 2014, Peter Zijlstra wrote:
> 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.
If memset (or any C library function)
On Fri, Feb 07, 2014 at 05:13:36PM +, Will Deacon wrote:
> Understood, but that doesn't explain why Paul wants to add ISB/isync
> instructions which affect the *CPU* rather than the compiler!
I doubt Paul wants it, but yeah, I'm curious about that proposal as
well, sounds like someone took a
On Fri, Feb 07, 2014 at 05:06:54PM +, Peter Zijlstra wrote:
> On Fri, Feb 07, 2014 at 04:55:48PM +, Will Deacon wrote:
> > Hi Paul,
> >
> > On Fri, Feb 07, 2014 at 04:50:28PM +, Paul E. McKenney wrote:
> > > On Fri, Feb 07, 2014 at 08:44:05AM +0100, Peter Zijlstra wrote:
> > > > On
On Fri, Feb 07, 2014 at 04:55:48PM +, Will Deacon wrote:
> Hi Paul,
>
> On Fri, Feb 07, 2014 at 04:50:28PM +, 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:
> > > >
Hi Paul,
On Fri, Feb 07, 2014 at 04:50:28PM +, 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,
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
On Fri, Feb 07, 2014 at 12:01:25PM +, Will Deacon wrote:
> Hello Torvald,
>
> It looks like Paul clarified most of the points I was trying to make
> (thanks Paul!), so I won't go back over them here.
>
> On Thu, Feb 06, 2014 at 09:09:25PM +, Torvald Riegel wrote:
> > Are you familiar
On Fri, Feb 07, 2014 at 10:13:40AM +0100, Torvald Riegel wrote:
> On Thu, 2014-02-06 at 20:06 -0800, Paul E. McKenney wrote:
> > On Thu, Feb 06, 2014 at 11:58:22PM +0100, Torvald Riegel wrote:
> > > On Thu, 2014-02-06 at 13:55 -0800, Paul E. McKenney wrote:
> > > > On Thu, Feb 06, 2014 at
Hello Torvald,
It looks like Paul clarified most of the points I was trying to make
(thanks Paul!), so I won't go back over them here.
On Thu, Feb 06, 2014 at 09:09:25PM +, Torvald Riegel wrote:
> Are you familiar with the formalization of the C11/C++11 model by Batty
> et al.?
>
On Thu, 2014-02-06 at 20:06 -0800, Paul E. McKenney wrote:
> On Thu, Feb 06, 2014 at 11:58:22PM +0100, Torvald Riegel wrote:
> > On Thu, 2014-02-06 at 13:55 -0800, Paul E. McKenney wrote:
> > > On Thu, Feb 06, 2014 at 10:09:25PM +0100, Torvald Riegel wrote:
> > > > On Thu, 2014-02-06 at 18:59
On Thu, 2014-02-06 at 20:06 -0800, Paul E. McKenney wrote:
On Thu, Feb 06, 2014 at 11:58:22PM +0100, Torvald Riegel wrote:
On Thu, 2014-02-06 at 13:55 -0800, Paul E. McKenney wrote:
On Thu, Feb 06, 2014 at 10:09:25PM +0100, Torvald Riegel wrote:
On Thu, 2014-02-06 at 18:59 +, Will
Hello Torvald,
It looks like Paul clarified most of the points I was trying to make
(thanks Paul!), so I won't go back over them here.
On Thu, Feb 06, 2014 at 09:09:25PM +, Torvald Riegel wrote:
Are you familiar with the formalization of the C11/C++11 model by Batty
et al.?
On Fri, Feb 07, 2014 at 10:13:40AM +0100, Torvald Riegel wrote:
On Thu, 2014-02-06 at 20:06 -0800, Paul E. McKenney wrote:
On Thu, Feb 06, 2014 at 11:58:22PM +0100, Torvald Riegel wrote:
On Thu, 2014-02-06 at 13:55 -0800, Paul E. McKenney wrote:
On Thu, Feb 06, 2014 at 10:09:25PM +0100,
On Fri, Feb 07, 2014 at 12:01:25PM +, Will Deacon wrote:
Hello Torvald,
It looks like Paul clarified most of the points I was trying to make
(thanks Paul!), so I won't go back over them here.
On Thu, Feb 06, 2014 at 09:09:25PM +, Torvald Riegel wrote:
Are you familiar with the
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
Hi Paul,
On Fri, Feb 07, 2014 at 04:50:28PM +, 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
On Fri, Feb 07, 2014 at 04:55:48PM +, Will Deacon wrote:
Hi Paul,
On Fri, Feb 07, 2014 at 04:50:28PM +, 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
On Fri, Feb 07, 2014 at 05:06:54PM +, Peter Zijlstra wrote:
On Fri, Feb 07, 2014 at 04:55:48PM +, Will Deacon wrote:
Hi Paul,
On Fri, Feb 07, 2014 at 04:50:28PM +, Paul E. McKenney wrote:
On Fri, Feb 07, 2014 at 08:44:05AM +0100, Peter Zijlstra wrote:
On Thu, Feb 06,
On Fri, Feb 07, 2014 at 05:13:36PM +, Will Deacon wrote:
Understood, but that doesn't explain why Paul wants to add ISB/isync
instructions which affect the *CPU* rather than the compiler!
I doubt Paul wants it, but yeah, I'm curious about that proposal as
well, sounds like someone took a
On Fri, Feb 07, 2014 at 04:55:48PM +, Will Deacon wrote:
Hi Paul,
On Fri, Feb 07, 2014 at 04:50:28PM +, 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
On Fri, 2014-02-07 at 18:06 +0100, Peter Zijlstra wrote:
On Fri, Feb 07, 2014 at 04:55:48PM +, Will Deacon wrote:
Hi Paul,
On Fri, Feb 07, 2014 at 04:50:28PM +, Paul E. McKenney wrote:
On Fri, Feb 07, 2014 at 08:44:05AM +0100, Peter Zijlstra wrote:
On Thu, Feb 06, 2014 at
On Fri, 2014-02-07 at 08:50 -0800, 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
On Fri, Feb 07, 2014 at 05:13:36PM +, Will Deacon wrote:
On Fri, Feb 07, 2014 at 05:06:54PM +, Peter Zijlstra wrote:
On Fri, Feb 07, 2014 at 04:55:48PM +, Will Deacon wrote:
Hi Paul,
On Fri, Feb 07, 2014 at 04:50:28PM +, Paul E. McKenney wrote:
On Fri, Feb 07, 2014
On Fri, 7 Feb 2014, Peter Zijlstra wrote:
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.
If memset (or any C library function)
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
On Fri, Feb 07, 2014 at 12:44:48AM +0100, Torvald Riegel wrote:
> On Thu, 2014-02-06 at 14:11 -0800, Paul E. McKenney wrote:
> > On Thu, Feb 06, 2014 at 10:17:03PM +0100, Torvald Riegel wrote:
> > > On Thu, 2014-02-06 at 11:27 -0800, Paul E. McKenney wrote:
> > > > On Thu, Feb 06, 2014 at
On Thu, Feb 06, 2014 at 11:58:22PM +0100, Torvald Riegel wrote:
> On Thu, 2014-02-06 at 13:55 -0800, Paul E. McKenney wrote:
> > On Thu, Feb 06, 2014 at 10:09:25PM +0100, Torvald Riegel wrote:
> > > On Thu, 2014-02-06 at 18:59 +, Will Deacon wrote:
> > > > On Thu, Feb 06, 2014 at 06:55:01PM
On Thu, 2014-02-06 at 14:11 -0800, Paul E. McKenney wrote:
> On Thu, Feb 06, 2014 at 10:17:03PM +0100, Torvald Riegel wrote:
> > On Thu, 2014-02-06 at 11:27 -0800, Paul E. McKenney wrote:
> > > On Thu, Feb 06, 2014 at 06:59:10PM +, Will Deacon wrote:
> > > > There are also so many ways to blow
On Fri, 7 Feb 2014, Torvald Riegel wrote:
> I think that if we have different options, there needs to be agreement
> on which to choose across the compilers, at the very least. I don't
> quite know how this looks like for GCC and LLVM, for example.
I'm not sure we even necessarily get
On Thu, 2014-02-06 at 22:13 +, Joseph S. Myers wrote:
> On Thu, 6 Feb 2014, Torvald Riegel wrote:
>
> > > It seems that nobody really
> > > agrees on exactly how the C11 atomics map to real architectural
> > > instructions on anything but the trivial architectures.
> >
> > There's certainly
On Thu, 6 Feb 2014, Torvald Riegel wrote:
> > It seems that nobody really
> > agrees on exactly how the C11 atomics map to real architectural
> > instructions on anything but the trivial architectures.
>
> There's certainly different ways to implement the memory model and those
> have to be
On Thu, 2014-02-06 at 13:55 -0800, Paul E. McKenney wrote:
> On Thu, Feb 06, 2014 at 10:09:25PM +0100, Torvald Riegel wrote:
> > On Thu, 2014-02-06 at 18:59 +, Will Deacon wrote:
> > > On Thu, Feb 06, 2014 at 06:55:01PM +, Ramana Radhakrishnan wrote:
> > > > On 02/06/14 18:25, David
On Thu, Feb 06, 2014 at 10:17:03PM +0100, Torvald Riegel wrote:
> On Thu, 2014-02-06 at 11:27 -0800, Paul E. McKenney wrote:
> > On Thu, Feb 06, 2014 at 06:59:10PM +, Will Deacon wrote:
> > > On Thu, Feb 06, 2014 at 06:55:01PM +, Ramana Radhakrishnan wrote:
> > > > On 02/06/14 18:25, David
On Thu, Feb 06, 2014 at 10:09:25PM +0100, Torvald Riegel wrote:
> On Thu, 2014-02-06 at 18:59 +, Will Deacon wrote:
> > On Thu, Feb 06, 2014 at 06:55:01PM +, Ramana Radhakrishnan wrote:
> > > On 02/06/14 18:25, David Howells wrote:
> > > >
> > > > Is it worth considering a move towards
On Thu, 2014-02-06 at 11:27 -0800, Paul E. McKenney wrote:
> On Thu, Feb 06, 2014 at 06:59:10PM +, Will Deacon wrote:
> > On Thu, Feb 06, 2014 at 06:55:01PM +, Ramana Radhakrishnan wrote:
> > > On 02/06/14 18:25, David Howells wrote:
> > > >
> > > > Is it worth considering a move towards
On Thu, 2014-02-06 at 18:59 +, Will Deacon wrote:
> On Thu, Feb 06, 2014 at 06:55:01PM +, Ramana Radhakrishnan wrote:
> > On 02/06/14 18:25, David Howells wrote:
> > >
> > > Is it worth considering a move towards using C11 atomics and barriers and
> > > compiler intrinsics inside the
On Thu, Feb 06, 2014 at 06:59:10PM +, Will Deacon wrote:
> On Thu, Feb 06, 2014 at 06:55:01PM +, Ramana Radhakrishnan wrote:
> > On 02/06/14 18:25, David Howells wrote:
> > >
> > > Is it worth considering a move towards using C11 atomics and barriers and
> > > compiler intrinsics inside
On Thu, Feb 6, 2014 at 10:25 AM, David Howells wrote:
>
> Is it worth considering a move towards using C11 atomics and barriers and
> compiler intrinsics inside the kernel? The compiler _ought_ to be able to do
> these.
I think that's a bad idea as a generic implementation, but it's quite
On Thu, Feb 06, 2014 at 06:55:01PM +, Ramana Radhakrishnan wrote:
> On 02/06/14 18:25, David Howells wrote:
> >
> > Is it worth considering a move towards using C11 atomics and barriers and
> > compiler intrinsics inside the kernel? The compiler _ought_ to be able to
> > do
> > these.
>
>
On 02/06/14 18:25, David Howells wrote:
Is it worth considering a move towards using C11 atomics and barriers and
compiler intrinsics inside the kernel? The compiler _ought_ to be able to do
these.
It sounds interesting to me, if we can make it work properly and
reliably. +
On Thu, Feb 06, 2014 at 06:25:49PM +, David Howells wrote:
>
> Is it worth considering a move towards using C11 atomics and barriers and
> compiler intrinsics inside the kernel? The compiler _ought_ to be able to do
> these.
Makes sense to me!
> One thing I'm not sure of, though, is how
On Thu, Feb 06, 2014 at 06:25:49PM +, David Howells wrote:
>
> Is it worth considering a move towards using C11 atomics and barriers and
> compiler intrinsics inside the kernel? The compiler _ought_ to be able to do
> these.
>
> One thing I'm not sure of, though, is how well gcc's atomics
Is it worth considering a move towards using C11 atomics and barriers and
compiler intrinsics inside the kernel? The compiler _ought_ to be able to do
these.
One thing I'm not sure of, though, is how well gcc's atomics will cope with
interrupt handlers touching atomics on CPUs without suitable
Hi all,
A few too large patches here, mostly as RFC to see if we want to continue with
this before I sink more time into it. I hope they make it out to the lists.
This all started with me wanting to implement atomic_sub_release() for all
archs, but I got side-tracked a bit and it ended up
Hi all,
A few too large patches here, mostly as RFC to see if we want to continue with
this before I sink more time into it. I hope they make it out to the lists.
This all started with me wanting to implement atomic_sub_release() for all
archs, but I got side-tracked a bit and it ended up
Is it worth considering a move towards using C11 atomics and barriers and
compiler intrinsics inside the kernel? The compiler _ought_ to be able to do
these.
One thing I'm not sure of, though, is how well gcc's atomics will cope with
interrupt handlers touching atomics on CPUs without suitable
On Thu, Feb 06, 2014 at 06:25:49PM +, David Howells wrote:
Is it worth considering a move towards using C11 atomics and barriers and
compiler intrinsics inside the kernel? The compiler _ought_ to be able to do
these.
One thing I'm not sure of, though, is how well gcc's atomics will
On Thu, Feb 06, 2014 at 06:25:49PM +, David Howells wrote:
Is it worth considering a move towards using C11 atomics and barriers and
compiler intrinsics inside the kernel? The compiler _ought_ to be able to do
these.
Makes sense to me!
One thing I'm not sure of, though, is how well
On 02/06/14 18:25, David Howells wrote:
Is it worth considering a move towards using C11 atomics and barriers and
compiler intrinsics inside the kernel? The compiler _ought_ to be able to do
these.
It sounds interesting to me, if we can make it work properly and
reliably. +
On Thu, Feb 06, 2014 at 06:55:01PM +, Ramana Radhakrishnan wrote:
On 02/06/14 18:25, David Howells wrote:
Is it worth considering a move towards using C11 atomics and barriers and
compiler intrinsics inside the kernel? The compiler _ought_ to be able to
do
these.
It sounds
On Thu, Feb 6, 2014 at 10:25 AM, David Howells dhowe...@redhat.com wrote:
Is it worth considering a move towards using C11 atomics and barriers and
compiler intrinsics inside the kernel? The compiler _ought_ to be able to do
these.
I think that's a bad idea as a generic implementation, but
On Thu, Feb 06, 2014 at 06:59:10PM +, Will Deacon wrote:
On Thu, Feb 06, 2014 at 06:55:01PM +, Ramana Radhakrishnan wrote:
On 02/06/14 18:25, David Howells wrote:
Is it worth considering a move towards using C11 atomics and barriers and
compiler intrinsics inside the kernel?
On Thu, 2014-02-06 at 18:59 +, Will Deacon wrote:
On Thu, Feb 06, 2014 at 06:55:01PM +, Ramana Radhakrishnan wrote:
On 02/06/14 18:25, David Howells wrote:
Is it worth considering a move towards using C11 atomics and barriers and
compiler intrinsics inside the kernel? The
On Thu, 2014-02-06 at 11:27 -0800, Paul E. McKenney wrote:
On Thu, Feb 06, 2014 at 06:59:10PM +, Will Deacon wrote:
On Thu, Feb 06, 2014 at 06:55:01PM +, Ramana Radhakrishnan wrote:
On 02/06/14 18:25, David Howells wrote:
Is it worth considering a move towards using C11
On Thu, Feb 06, 2014 at 10:09:25PM +0100, Torvald Riegel wrote:
On Thu, 2014-02-06 at 18:59 +, Will Deacon wrote:
On Thu, Feb 06, 2014 at 06:55:01PM +, Ramana Radhakrishnan wrote:
On 02/06/14 18:25, David Howells wrote:
Is it worth considering a move towards using C11 atomics
On Thu, Feb 06, 2014 at 10:17:03PM +0100, Torvald Riegel wrote:
On Thu, 2014-02-06 at 11:27 -0800, Paul E. McKenney wrote:
On Thu, Feb 06, 2014 at 06:59:10PM +, Will Deacon wrote:
On Thu, Feb 06, 2014 at 06:55:01PM +, Ramana Radhakrishnan wrote:
On 02/06/14 18:25, David Howells
On Thu, 2014-02-06 at 13:55 -0800, Paul E. McKenney wrote:
On Thu, Feb 06, 2014 at 10:09:25PM +0100, Torvald Riegel wrote:
On Thu, 2014-02-06 at 18:59 +, Will Deacon wrote:
On Thu, Feb 06, 2014 at 06:55:01PM +, Ramana Radhakrishnan wrote:
On 02/06/14 18:25, David Howells wrote:
On Thu, 6 Feb 2014, Torvald Riegel wrote:
It seems that nobody really
agrees on exactly how the C11 atomics map to real architectural
instructions on anything but the trivial architectures.
There's certainly different ways to implement the memory model and those
have to be specified
On Thu, 2014-02-06 at 22:13 +, Joseph S. Myers wrote:
On Thu, 6 Feb 2014, Torvald Riegel wrote:
It seems that nobody really
agrees on exactly how the C11 atomics map to real architectural
instructions on anything but the trivial architectures.
There's certainly different ways
On Fri, 7 Feb 2014, Torvald Riegel wrote:
I think that if we have different options, there needs to be agreement
on which to choose across the compilers, at the very least. I don't
quite know how this looks like for GCC and LLVM, for example.
I'm not sure we even necessarily get
On Thu, 2014-02-06 at 14:11 -0800, Paul E. McKenney wrote:
On Thu, Feb 06, 2014 at 10:17:03PM +0100, Torvald Riegel wrote:
On Thu, 2014-02-06 at 11:27 -0800, Paul E. McKenney wrote:
On Thu, Feb 06, 2014 at 06:59:10PM +, Will Deacon wrote:
There are also so many ways to blow your head
On Thu, Feb 06, 2014 at 11:58:22PM +0100, Torvald Riegel wrote:
On Thu, 2014-02-06 at 13:55 -0800, Paul E. McKenney wrote:
On Thu, Feb 06, 2014 at 10:09:25PM +0100, Torvald Riegel wrote:
On Thu, 2014-02-06 at 18:59 +, Will Deacon wrote:
On Thu, Feb 06, 2014 at 06:55:01PM +,
On Fri, Feb 07, 2014 at 12:44:48AM +0100, Torvald Riegel wrote:
On Thu, 2014-02-06 at 14:11 -0800, Paul E. McKenney wrote:
On Thu, Feb 06, 2014 at 10:17:03PM +0100, Torvald Riegel wrote:
On Thu, 2014-02-06 at 11:27 -0800, Paul E. McKenney wrote:
On Thu, Feb 06, 2014 at 06:59:10PM +,
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
501 - 570 of 570 matches
Mail list logo
