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