Re: memory model, READ_ONCE

s is not allowed in C11. This > is transformed to: > > void f(int n, float *a) > { > int tmp = position; >for (int i = 0; i < n; i++) >if (a[i] < 0) >tmp = i; >position = tmp; > } > > So if there is a write, no other thread can

Re: memory model, READ_ONCE

On Sat, 1 Mar 2025, Martin Uecker via Gcc wrote: > > > What was the reason to disallow those optimizations that  > > > could be allowed by default? > > > > -fallow-store-data-races guards transforms that we know to be incorrect > > for source code that may become a part of a multithreaded progr

Re: memory model, READ_ONCE

on = i; > } Now I wonder why this is not allowed in C11. This is transformed to: void f(int n, float *a) { int tmp = position; for (int i = 0; i < n; i++) if (a[i] < 0) tmp = i; position = tmp; } So if there is a write, no other thread can read or wr

Re: memory model, READ_ONCE

On Sat, 1 Mar 2025, Martin Uecker via Gcc wrote: > Sorry for being a bit slow.  This is still not clear to me. > > In vect/pr65206.c the following loop can be vectorized > with -fallow-store-data-races. > > #define N 1024 > > double a[N], b[N]; > > void foo () > { > for (int i = 0; i < N;

Re: memory model, READ_ONCE

Am Freitag, dem 28.02.2025 um 21:39 +0300 schrieb Alexander Monakov: > On Fri, 28 Feb 2025, Martin Uecker via Gcc wrote: > > > > > I have one follow-up question: What is the reason > > that we have stronger semantics for stores by default (i.e. > > when not using -fallow-store-data-races) than f

Re: memory model, READ_ONCE

Am Freitag, dem 28.02.2025 um 20:21 +0100 schrieb Richard Biener: > > > Am 28.02.2025 um 20:02 schrieb Martin Uecker : > > > > Am Freitag, dem 28.02.2025 um 21:39 +0300 schrieb Alexander Monakov: > > > > On Fri, 28 Feb 2025, Martin Uecker via Gcc wrote: > > > > > > > > > > > > I have one follo

Re: memory model, READ_ONCE

; > > Hi all, > > > > > > one area where the Linux kernel people are unhappy with C's > > > memory model is where they now have to use the READ_ONCE, > > > WRITE_ONCE macros. These are cases where they do not want > > > a compiler to duplicate a

Re: memory model, READ_ONCE

> Am 28.02.2025 um 20:02 schrieb Martin Uecker : > > Am Freitag, dem 28.02.2025 um 21:39 +0300 schrieb Alexander Monakov: >>> On Fri, 28 Feb 2025, Martin Uecker via Gcc wrote: >>> >>> >>> I have one follow-up question: What is the reason >>> that we have stronger semantics for stores by def

Re: memory model, READ_ONCE

On Fri, 28 Feb 2025, Martin Uecker via Gcc wrote: > > I have one follow-up question: What is the reason > that we have stronger semantics for stores by default (i.e. > when not using -fallow-store-data-races) than for reads > given that the standard would allow more freedom. Why would it? On

Re: memory model, READ_ONCE

Am Freitag, dem 28.02.2025 um 08:18 +0100 schrieb Richard Biener via Gcc: > On Fri, Feb 28, 2025 at 8:01 AM Martin Uecker wrote: > > > > > > Hi all, > > > > one area where the Linux kernel people are unhappy with C's > > memory model is where they n

Re: memory model, READ_ONCE

On Fri, Feb 28, 2025 at 8:01 AM Martin Uecker wrote: > > > Hi all, > > one area where the Linux kernel people are unhappy with C's > memory model is where they now have to use the READ_ONCE, > WRITE_ONCE macros. These are cases where they do not want > a compiler

memory model, READ_ONCE

Hi all, one area where the Linux kernel people are unhappy with C's memory model is where they now have to use the READ_ONCE, WRITE_ONCE macros. These are cases where they do not want a compiler to duplicate a load, e.g. to reload a value later because registers were not available to cac

[RISC-V] built-in atomic function implementation involving RISC-V memory model

Hi, As stated in the comments of riscv_print_operand (the latest version of gcc/config/riscv/riscv.cc), the RISCV-specific operand code 'A', which is used in the implementation of 'atomic_cas_value_strong' in sync.md, is the atomic operation suffix for memory model OP. Ho

Re: 6.55 Built-in Functions for Memory Model Aware Atomic Operations

N.B. I already answered this when you sent it to the libstdc++ list, read past the first line of my reply: https://gcc.gnu.org/pipermail/libstdc++/2021-July/052932.html On Wed, 21 Jul 2021 at 14:00, Amar Memic wrote: > > > Hi,6.55 Built-in Functions for Memory Model Aware Atomic O

6.55 Built-in Functions for Memory Model Aware Atomic Operations

Hi,6.55 Built-in Functions for Memory Model Aware Atomic Operations (https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html)  says:Note that the ‘__atomic’ builtins assume that programs will conform to the C++11 memory model. In particular, they assume that programs are free of

How to prune tests that are too large for a tiny memory model in libstdc++?

Hi all, I'm seeing some relocation truncation failures in the libstdc++ testsuite where the test is too large to fit into the memory model. In the gcc testsuite we mark these tests as unsupported using something like the below fragment in gcc-dg.exp if { [regexp "(^|\n)\[^\n\]*:

Re: Help with C++11 memory model on zSeries

ing > instruction must be in the CPU-2 loop to ensure that CPU 2 will again > fetch from location A. > > Does the new C/C++ memory model allow that kind of infinite loop > even for sequentially-consistent atomic loads? The draft text was: > > [29.3.3] > T

Help with C++11 memory model on zSeries

because CPU 2 may already have fetched from location A for every execution of the CLI instruction. A serializing instruction must be in the CPU-2 loop to ensure that CPU 2 will again fetch from location A. Does the new C/C++ memory model allow that kind of infinite loop even for sequentiall

Re: x86-64 medium memory model

The small memory model will not do since I want to put data at other distinct addresses above 4G. I also want to place the heap at yet another address interval. This way it becomes easy to separate out code, data and heap references, and making sure that pointers are valid. The primary reason

Re: x86-64 medium memory model

gt; problems with GCC when using this memory model. > Have you tried PIE with small model? You can place your binaries above 4G with better performance. -- H.J.

x86-64 medium memory model

I'm working on OS-adaptations for an OS that would use x86-64 applications that are located above 4G, but not in the upper area. Binutils provide a function to be able to set the start of text to above 4G, but there are problems with GCC when using this memory model. The first issue has

Re: New Bugzilla keyword for memory model bugs?

Hello Steven, Steven Bosscher wrote: Can someone please add a BZ keyword for the C11/C++11 memory model? I think it would be good to tag missed-optimizations or wrong-code bugs for the memory model with such a special keyword to have a BZ search find them quickly. Adding a keyword is simple

Re: Memory Model

gcc.gnu.org bounced the previous email for some reason... On 03/12/2012 06:51 PM, Joe Gottman wrote: On 3/12/2012 8:44 AM, Andrew MacLeod wrote: On 03/10/2012 09:17 AM, Joe Gottman wrote: According to the news on the front page, the C++11 memory model has been added to gcc. But C++11

Re: Memory Model

On 3/12/12, Joe Gottman wrote: > On 3/12/2012 8:44 AM, Andrew MacLeod wrote: > > On 03/10/2012 09:17 AM, Joe Gottman wrote: > > > According to the news on the front page, the C++11 > > > memory model has been added to gcc. But C++11 status page > > > (http://g

Re: Memory Model

On 3/12/2012 8:44 AM, Andrew MacLeod wrote: On 03/10/2012 09:17 AM, Joe Gottman wrote: According to the news on the front page, the C++11 memory model has been added to gcc. But C++11 status page (http://gcc.gnu.org/projects/cxx0x.html) says that it hasn't. Is this an over

Re: Memory Model

On 03/10/2012 09:17 AM, Joe Gottman wrote: According to the news on the front page, the C++11 memory model has been added to gcc. But C++11 status page (http://gcc.gnu.org/projects/cxx0x.html) says that it hasn't. Is this an oversight? Atomic support with memory model parameters

Memory Model

According to the news on the front page, the C++11 memory model has been added to gcc. But C++11 status page (http://gcc.gnu.org/projects/cxx0x.html) says that it hasn't. Is this an oversight? Joe Gottman

Re: C++ memory model... What to do with libatomic

On 11/30/2011 10:07 AM, Andrew MacLeod wrote: > PS. Reflecting upon it, I wonder if it could be a part of the gcc > libraries like libgomp or libitm are. During configuration we could > check to see if there is an existing libatomic in the system, and if > there is NOT, enable building libatomic

C++ memory model... What to do with libatomic

Libstdc++-v3 use to provide a locked implementation of classes for sizes which didn't have lock-free support. That was removed for this release as it caused a program compiled with a specific version of GCC to be locked into that implementation. The design criteria for the new __atomic builti

C++0x memory model code gen

I've created a wiki page with the changes to codegen for the C++ memory model that we're working on implementing. http://gcc.gnu.org/wiki/Atomic/GCCMM/CodeGen in a nutshell, it expands the set of __sync atomic builtin's to take another parameter for memory model, and the

Re: C++0x Memory model and gcc

lt in a load or store. That's further work >> >> of course, but these options are laying some of the groundwork. >> > >> > Are you and the other proponents of that memory model seriously >> > proposing it as an alternative to explicit locking via atomic b

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 con

Re: C++0x Memory model and gcc

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 options are laying some of the groundwork. > > >

Re: C++0x Memory model and gcc

urther work > >> of course, but these options are laying some of the groundwork. > > > > Are you and the other proponents of that memory model seriously > > proposing it as an alternative to explicit locking via atomic builtins > > (that map to some form of atomi

Re: C++0x Memory model and gcc

in the best case, simply result in a load or store. That's further work of course, but these options are laying some of the groundwork. Are you and the other proponents of that memory model seriously proposing it as an alternative to explicit locking via atomic builtins (that map to

Re: C++0x Memory model and gcc

r, 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 options are laying some of the groundwork. > > Are you and the other proponents of that memo

Re: C++0x Memory model and gcc

hem for speed... and in the > best case, simply result in a load or store. That's further work of > course, but these options are laying some of the groundwork. Are you and the other proponents of that memory model seriously proposing it as an alternative to explicit locking via atom

Re: C++0x Memory model and gcc

? Right. Its just a single processor memory model, so it doesn't limit any optimizations. Hmm, though now that I think about it, I'm not exactly sure what I mean by "explicit synchronization". Standard libraries (boost threads, the upcoming std::thread) provide thi

Re: C++0x Memory model and gcc

done, right? > > Right. Its just a single processor memory model, so it doesn't limit > any optimizations. Hmm, though now that I think about it, I'm not exactly sure what I mean by "explicit synchronization". Standard libraries (boost threads, the upcoming std::thread

Re: C++0x Memory model and gcc

? Right. Its just a single processor memory model, so it doesn't limit any optimizations. Andrew

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

k that "safe" lets the user code assumes >> the sequential consistency model. I'd use -fmemory-model=conformant or >> something like that for the model where the compiler assumes that the user >> code respect the constraint led out for it by the standard. As which &

Re: C++0x Memory model and gcc

l where the compiler assumes that the user code respect the constraint led out for it by the standard. As which constraints are put on user code depend on the languages -- Java has its own memory model which AFAIK is more constraining than C++ and I think Ada has its own but my Ada programming days a

Re: C++0x Memory model and gcc

s that the user code respect the constraint led out for it by the standard. As which constraints are put on user code depend on the languages -- Java has its own memory model which AFAIK is more constraining than C++ and I think Ada has its own but my Ada programming days are too far for me to comm

[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

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 th

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, s

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,

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

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 st

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 imp

Re: [PATCH][RFC] Adjust the middle-end memory model

Richard Guenther wrote: > Yes, that's the primary motivation of this patch. Can I take this > as an approval for the C++ frontend changes? OK. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: [PATCH][RFC] Adjust the middle-end memory model

On Wed, 20 May 2009, Mark Mitchell wrote: > Richard Guenther wrote: > > > int i; > > float f; > > void foo() > > { > > int *p = (int *)malloc(sizeof(int)); > > *p = 1; > > i = *p; > > float *q = (float *)p; > > *q = 2.0; > > f = *q; > > } > > Yes, I think that's a valid program too.

Re: [PATCH][RFC] Adjust the middle-end memory model

Richard Guenther wrote: > int i; > float f; > void foo() > { > int *p = (int *)malloc(sizeof(int)); > *p = 1; > i = *p; > float *q = (float *)p; > *q = 2.0; > f = *q; > } Yes, I think that's a valid program too. I'm OK with giving up this optimization; clearly we need to be correct f

Re: [PATCH][RFC] Adjust the middle-end memory model

On Wed, 20 May 2009, Mark Mitchell wrote: > Richard Guenther wrote: > > >> void f(float *f, int *n) { > >> for (int i = 0; i < *n; ++i) { > >> f[i] *= 2; > >> } > >> } > > > The difference is if you want to sink a load from *n beyond the > > store to f[i] - in which case you as

Re: [PATCH][RFC] Adjust the middle-end memory model

Richard Guenther wrote: >> void f(float *f, int *n) { >> for (int i = 0; i < *n; ++i) { >> f[i] *= 2; >> } >> } > The difference is if you want to sink a load from *n beyond the > store to f[i] - in which case you ask if there is an anti-dependence > which we cannot exclude in t

Re: [PATCH][RFC] Adjust the middle-end memory model

On Tue, 19 May 2009, Mark Mitchell wrote: > Richard Guenther wrote: > > >> - The tree alias oracle got similar functionality, refs_anti_dependent > >>and refs_output_dependent and the tree level data dependence > >>analysis code makes use of these. > > Do we still use TBAA for the origi

Re: [PATCH][RFC] Adjust the middle-end memory model

Richard Guenther wrote: >> - The tree alias oracle got similar functionality, refs_anti_dependent >>and refs_output_dependent and the tree level data dependence >>analysis code makes use of these. Do we still use TBAA for the original motivating reason for adding it, e.g.,: void f(flo

Re: [PATCH][RFC] Adjust the middle-end memory model

On Fri, 8 May 2009, Richard Guenther wrote: > > This adjusts the middle-end memory model to properly honor type-based > aliasing rules set by the C and C++ standards. > > The bulk of the patch gets rid of our previous attempts to fix > the issues around placeme