Re: C++0x Memory model and gcc

Michael Matz writes: > On Mon, 17 May 2010, Ian Lance Taylor wrote: > >> >> Since the atomic operations are being built into the compiler, the >> >> intent is to eventually optimize and inline them for speed... and in >> >> the best case, simply result in a load or store. That's further work >

Re: C++0x Memory model and gcc

Michael Matz wrote: Hi, On Mon, 17 May 2010, Andrew MacLeod wrote: The guarantees you seem to want to establish by the proposed memory model. Possibly I misunderstood. I'm not 100% sure on the guarantees you want to establish. The proposed model seems to merge multiple concepts together

Re: C++0x Memory model and gcc

Hi, On Mon, 17 May 2010, Andrew MacLeod wrote: > > > Well, you get the same thing you get today. Any synchronization > > > done via a function call will tend to be correct since we never move > > > shared memory operations across calls. Depending on your > > > application, the types of data

Re: C++0x Memory model and gcc

Hi, On Mon, 17 May 2010, Ian Lance Taylor wrote: > >> Since the atomic operations are being built into the compiler, the > >> intent is to eventually optimize and inline them for speed... and in > >> the best case, simply result in a load or store. That's further work > >> of course, but these

Re: C++0x Memory model and gcc

Michael Matz wrote: Hi, On Wed, 12 May 2010, Andrew MacLeod wrote: Well, you get the same thing you get today. Any synchronization done via a function call will tend to be correct since we never move shared memory operations across calls. Depending on your application, the types of data

Re: C++0x Memory model and gcc

Michael Matz writes: > On Wed, 12 May 2010, Andrew MacLeod wrote: > >> Well, you get the same thing you get today. Any synchronization done >> via a function call will tend to be correct since we never move shared >> memory operations across calls. Depending on your application, the >> types

Re: C++0x Memory model and gcc

Hi, On Wed, 12 May 2010, Andrew MacLeod wrote: > Well, you get the same thing you get today. Any synchronization done > via a function call will tend to be correct since we never move shared > memory operations across calls. Depending on your application, the > types of data races the option

Re: C++0x Memory model and gcc

Miles Bader wrote: Andrew MacLeod writes: -fmemory-model=single - Enable all data races introductions, as they are today. (relax all 4 internal restrictions.) One could still use this mode with a multi-threaded program as long as explicit synchronization is done, right?

Re: C++0x Memory model and gcc

Andrew MacLeod writes: >>> -fmemory-model=single - Enable all data races introductions, as they >>> are today. (relax all 4 internal restrictions.) >> >> One could still use this mode with a multi-threaded program as long as >> explicit synchronization is done, right? > > Right. Its just a si

Re: C++0x Memory model and gcc

Miles Bader wrote: Andrew MacLeod writes: -fmemory-model=single - Enable all data races introductions, as they are today. (relax all 4 internal restrictions.) One could still use this mode with a multi-threaded program as long as explicit synchronization is done, right? Right

Re: C++0x Memory model and gcc

Andrew MacLeod writes: > -fmemory-model=single - Enable all data races introductions, as they > are today. (relax all 4 internal restrictions.) One could still use this mode with a multi-threaded program as long as explicit synchronization is done, right? -Miles -- Road, n. A strip of land

Re: C++0x Memory model and gcc

On 05/10/2010 12:39 AM, Ian Lance Taylor wrote: Albert Cohen writes: I agree. Or even, =c++0x or =gnu++0x On the other hand, I fail to see the differen between =single and =fast, and the explanation about "the same memory word" is not really relevant as memory models typically tell you ab

Re: C++0x Memory model and gcc

Albert Cohen writes: > Jean-Marc Bourguet wrote: >>> -fmemory-model=single >>> Assume single threaded execution, which also means no signal >>> handlers. >>> -fmemory-model=fast >>> The user is responsible for all synchronization. Accessing >>> the same me

Re: C++0x Memory model and gcc

Jean-Marc Bourguet wrote: -fmemory-model=single Assume single threaded execution, which also means no signal handlers. -fmemory-model=fast The user is responsible for all synchronization. Accessing the same memory words from different threads may break

Re: C++0x Memory model and gcc

-fmemory-model=single Assume single threaded execution, which also means no signal handlers. -fmemory-model=fast The user is responsible for all synchronization. Accessing the same memory words from different threads may break unpredictably. -fm

[Fwd: Re: C++0x Memory model and gcc]

Oops, didn't reply all... Original Message Subject: Re: C++0x Memory model and gcc Date: Fri, 07 May 2010 10:37:40 -0400 From: Andrew MacLeod To: Ian Lance Taylor References: <4be2e39a.5060...@redhat.com> <4be2ecdb.2040...@redhat.com>

Re: C++0x Memory model and gcc

Andrew MacLeod writes: > They are independent as far as dependencies within this compilation unit. > The problem is if thread number 2 is performing > a.j = val > b.i = val2 > > now there are data races on both A and B if we load/store full words > and the struct was something like: struct { >

Re: C++0x Memory model and gcc

Ian Lance Taylor wrote: > -fmemory-model=single > Assume single threaded execution, which also means no signal > handlers. > -fmemory-model=fast > The user is responsible for all synchronization. Accessing > the same memory words from different threads may

Re: C++0x Memory model and gcc

Richard Guenther wrote: On Thu, May 6, 2010 at 6:22 PM, Andrew MacLeod wrote: Richard Guenther wrote: I would have hoped that only data races between independent objects are covered, thus tmp = a.i; b.j = tmp; would qualify as a load of a and a store to b as far as dependencies are co

Re: C++0x Memory model and gcc

On Thu, May 6, 2010 at 6:22 PM, Andrew MacLeod wrote: > Richard Guenther wrote: >> >> On Thu, May 6, 2010 at 5:50 PM, Richard Guenther >> wrote: >> >>> >>> First let me say that the C++ memory model is crap when it >>> forces data-races to be avoided for unannotated data like >>> the examples for

Re: C++0x Memory model and gcc

Ian Lance Taylor wrote: Andrew MacLeod writes: I've been working for a while on understanding how the new memory model and Atomics work, and what the impacts are on GCC. Thanks for looking at this. One issue I didn't see clearly was how to actually implement this in the compiler. F

Re: C++0x Memory model and gcc

Andrew MacLeod writes: > I've been working for a while on understanding how the new memory > model and Atomics work, and what the impacts are on GCC. Thanks for looking at this. One issue I didn't see clearly was how to actually implement this in the compiler. For example, speculated stores ar

Re: C++0x Memory model and gcc

Richard Guenther wrote: On Thu, May 6, 2010 at 5:50 PM, Richard Guenther wrote: First let me say that the C++ memory model is crap when it forces data-races to be avoided for unannotated data like the examples for packed data. And it isn't consistent across the board, since neighbouri

Re: C++0x Memory model and gcc

Joseph S. Myers wrote: On Thu, 6 May 2010, Andrew MacLeod wrote: - Implementation of atomic variables and synchronization modes as well as a new infrastructure to test these types of things. I presume you've read the long thread starting at

Re: C++0x Memory model and gcc

On Thu, May 6, 2010 at 5:50 PM, Richard Guenther wrote: > On Thu, May 6, 2010 at 5:43 PM, Andrew MacLeod wrote: >> I've been working for a while on understanding how the new memory model and >> Atomics work, and what the impacts are on GCC. >> >> It would be ideal to get as many of these changes

Re: C++0x Memory model and gcc

On Thu, 6 May 2010, Andrew MacLeod wrote: > - Implementation of atomic variables and synchronization modes > as well as a new infrastructure to test these types of things. I presume you've read the long thread starting at regarding the issues in

Re: C++0x Memory model and gcc

On Thu, May 6, 2010 at 5:43 PM, Andrew MacLeod wrote: > I've been working for a while on understanding how the new memory model and > Atomics work, and what the impacts are on GCC. > > It would be ideal to get as many of these changes into GCC 4.6 as possible. > I've started work on some of the mo

C++0x Memory model and gcc

I've been working for a while on understanding how the new memory model and Atomics work, and what the impacts are on GCC. It would be ideal to get as many of these changes into GCC 4.6 as possible. I've started work on some of the modifications and testing, and the overall impact on GCC shou