On 05/04/2016 05:35, Pranith Kumar wrote:
> > You can find some information at
> > https://bugzilla.redhat.com/show_bug.cgi?id=1142857 and
>
> This bug seems to be out-of-bounds. I get a message saying that the
> bug has been restricted for internal development processes.
Sorry, it's open now.
On Mon, Apr 4, 2016 at 1:03 PM, Paolo Bonzini wrote:
>>
>> Quoting
>> http://www.inf.pucrs.br/~flash/progeng2/cppreference/w/cpp/atomic/atomic_thread_fencehtml.html:
>>
>> "Establishes memory synchronization ordering of non-atomic and relaxed
>> atomic accesses"
>
> You can
On 04/04/2016 19:03, Paolo Bonzini wrote:
> I've looked at private email from that time and I was pointed to this
> sentence in GCC's manual, which says the opposite:
>
> "Note that in the C++11 memory model, fences (e.g.,
> ‘__atomic_thread_fence’) take effect in combination with other
On 04/04/2016 18:26, Pranith Kumar wrote:
> Hi Paolo,
>
> On Mon, Apr 4, 2016 at 4:14 AM, Paolo Bonzini wrote:
>>
>> The issue is that atomic_thread_fence() only affects other atomic
>> operations, while smp_rmb() and smp_wmb() affect normal loads and stores
>> as well.
>
Hi Paolo,
On Mon, Apr 4, 2016 at 4:14 AM, Paolo Bonzini wrote:
>
> The issue is that atomic_thread_fence() only affects other atomic
> operations, while smp_rmb() and smp_wmb() affect normal loads and stores
> as well.
That is different from what I understand what
On 01/04/2016 22:35, Pranith Kumar wrote:; barrier(); })
> I could not really understand why we need to wrap the fence with
> barrier()'s. There are three parts to my confusion. Let me ask one after the
> other.
>
> On x86, __atomic_thread_fence(__ATOMIC_SEQ_CST) will generate an mfence
>
Hi Alex,
I have one question inline below.
Alex Bennée writes:
> The __atomic primitives have been available since GCC 4.7 and provide
> a richer interface for describing memory ordering requirements. As a
> bonus by using the primitives instead of hand-rolled functions we can
> use tools such
James Hogan writes:
> Hi Alex,
>
> On Thu, Jan 28, 2016 at 10:15:17AM +, Alex Bennée wrote:
>> The __atomic primitives have been available since GCC 4.7 and provide
>> a richer interface for describing memory ordering requirements. As a
>> bonus by using the
On 1 April 2016 at 15:30, James Hogan wrote:
> Hi Alex,
>
> On Thu, Jan 28, 2016 at 10:15:17AM +, Alex Bennée wrote:
>> The __atomic primitives have been available since GCC 4.7 and provide
>> a richer interface for describing memory ordering requirements. As a
>>
Hi Alex,
On Thu, Jan 28, 2016 at 10:15:17AM +, Alex Bennée wrote:
> The __atomic primitives have been available since GCC 4.7 and provide
> a richer interface for describing memory ordering requirements. As a
> bonus by using the primitives instead of hand-rolled functions we can
> use tools
On 29/01/2016 17:06, Alex Bennée wrote:
>
> Paolo Bonzini writes:
>
>> On 28/01/2016 11:15, Alex Bennée wrote:
>>> +/* atomic_mb_read/set semantics map Java volatile variables. They are
>>> + * less expensive on some platforms (notably POWER & ARM) than fully
>>> + *
On 4 February 2016 at 12:40, Paolo Bonzini wrote:
> I don't know the exact feature test, and I think ARMv7's penalty is much
> less because processors are slower, with a less deep pipeline and
> usually not used in SMP configurations.
Most v7 cores are SMP, and especially
Paolo Bonzini writes:
> On 28/01/2016 11:15, Alex Bennée wrote:
>> +/* atomic_mb_read/set semantics map Java volatile variables. They are
>> + * less expensive on some platforms (notably POWER & ARM) than fully
>> + * sequentially consistent operations.
>> + *
>> + * As
The __atomic primitives have been available since GCC 4.7 and provide
a richer interface for describing memory ordering requirements. As a
bonus by using the primitives instead of hand-rolled functions we can
use tools such as the AddressSanitizer which need the use of well
defined APIs for its
On 28/01/2016 11:15, Alex Bennée wrote:
> +/* atomic_mb_read/set semantics map Java volatile variables. They are
> + * less expensive on some platforms (notably POWER & ARM) than fully
> + * sequentially consistent operations.
> + *
> + * As long as they are used as paired operations they are
15 matches
Mail list logo