Re: GCC interpretation of C11 atomics (DR 459)

Torvald, I think this discussion, indeed, gets pointless. Some of your responses clearly take my comments out of larger picture and context of the discussion. One thing is clear that either implementation is fine with the standard (formally speaking) simply because the standard allows too much

Re: GCC interpretation of C11 atomics (DR 459)

On Tue, 2018-02-27 at 19:32 +, Ruslan Nikolaev wrote: > > > But we're not talking about that special case of 128b types here. The > > majority of synchronization doesn't need more than machine word size. > Then why do you worry about read-only access for 128b types? (it is a special > case

Re: GCC interpretation of C11 atomics (DR 459)

> But we're not talking about that special case of 128b types here.  The > majority of synchronization doesn't need more than machine word size. Then why do you worry about read-only access for 128b types? (it is a special case anyway). > No, such a program would have a bug anyway.  It

Re: GCC interpretation of C11 atomics (DR 459)

On Tue, 2018-02-27 at 17:29 +, Ruslan Nikolaev wrote: > > > > Consider a producer-consumer relationship between two processes where > > the producer doesn't want to wait for the consumer. For example, the > > producer could be an application that's being traced, and the consumer > > is a

Re: GCC interpretation of C11 atomics (DR 459)

On 27 Feb 2018, at 17:07, Torvald Riegel wrote: > > On Tue, 2018-02-27 at 16:40 +, Simon Wright wrote: >> On 27 Feb 2018, at 12:56, Ruslan Nikolaev via gcc wrote: >>> >>> And all this mess to accommodate almost non-existent case when someone >>> wants

Re: GCC interpretation of C11 atomics (DR 459)

> Consider a producer-consumer relationship between two processes where > the producer doesn't want to wait for the consumer.  For example, the > producer could be an application that's being traced, and the consumer > is a trace aggregation tool.  The producer can provide a read-only > mapping

Re: GCC interpretation of C11 atomics (DR 459)

On Tue, 2018-02-27 at 16:40 +, Simon Wright wrote: > On 27 Feb 2018, at 12:56, Ruslan Nikolaev via gcc wrote: > > > > And all this mess to accommodate almost non-existent case when someone > > wants to use atomic_load on read-only memory for wide types, in which no > >

Re: Fw: GCC interpretation of C11 atomics (DR 459)

Torvald, thank you for your output, but I think, this discussion gets a little pointless. There is nothing else I can add since gcc folks are reluctant to this change anyway. In my opinion, there is no compelling reason against such an implementation (it is perfectly fine with the standard,

Re: GCC interpretation of C11 atomics (DR 459)

On 02/27/2018 05:40 PM, Simon Wright wrote: Sorry to butt in, but - if it's ROM why would you need atomic load anyway? (of course, if it's just a constant view of the object, reason is obvious) On many systems, the read-only nature of a memory region is a thread-local or process-local

Re: GCC interpretation of C11 atomics (DR 459)

On 27 Feb 2018, at 12:56, Ruslan Nikolaev via gcc wrote: > > And all this mess to accommodate almost non-existent case when someone wants > to use atomic_load on read-only memory for wide types, in which no good > solution exists anyway Sorry to butt in, but - if it's ROM why

Re: Fw: GCC interpretation of C11 atomics (DR 459)

On Tue, 2018-02-27 at 13:16 +, Ruslan Nikolaev via gcc wrote: > > 3) Torvald pointed out further considerations such as users expecting > > lock-free atomic loads to be faster than stores. > > Is it even true? Is it faster to use some global lock (implemented through > RMW) than a single

Re: Fw: GCC interpretation of C11 atomics (DR 459)

On Tue, 2018-02-27 at 13:04 +, Szabolcs Nagy wrote: > the solutions is to add a language extension I think this only needs a library interface, at least when we're just considering the __atomic builtins. On the C/C++ level, it might amount to just another atomic type, which only has a CAS

[Bug c/84563] GCC interpretation of C11 atomics (DR 459)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84563 torvald at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED

Re: Fw: GCC interpretation of C11 atomics (DR 459)

On Tue, 2018-02-27 at 12:56 +, Ruslan Nikolaev via gcc wrote: > But, of course, it is kind of annoying that double-width types (and that also > includes potentially 64-bit on some 32-bit processors, e.g. i586 also has > cmpxchg8b and no official way to read atomically otherwise) need special

Re: Fw: GCC interpretation of C11 atomics (DR 459)

> 1) your proposal would make gcc non-conforming to iso c unless it changes how > static const objects are emitted. I do not think, ISO C requires to put const objects to .rodata. And it is easily solved by not placing it there for _Atomic objects that cannot be safely loaded from read-only

Re: Fw: GCC interpretation of C11 atomics (DR 459)

On 27/02/18 12:56, Ruslan Nikolaev wrote: Formally speaking, either implementation satisfies C11 because the standard allows much leeway in the interpretation here. no, 1) your proposal would make gcc non-conforming to iso c unless it changes how static const objects are emitted. 2) the two

Re: Fw: GCC interpretation of C11 atomics (DR 459)

Formally speaking, either implementation satisfies C11 because the standard allows much leeway in the interpretation here. But, of course, it is kind of annoying that double-width types (and that also includes potentially 64-bit on some 32-bit processors, e.g. i586 also has cmpxchg8b and no

[Bug c/84563] GCC interpretation of C11 atomics (DR 459)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84563 torvald at gcc dot gnu.org changed: What|Removed |Added CC||torvald at gcc dot gnu.org

Re: Fw: GCC interpretation of C11 atomics (DR 459)

On Mon, 2018-02-26 at 22:45 +, Ruslan Nikolaev via gcc wrote: > Thanks, everyone, for the output, it is very useful. I am just proposing to > consider the change unless there are clear roadblocks. (Either design choice > is probably OK with respect to the standard formally speaking, but

Re: Fw: GCC interpretation of C11 atomics (DR 459)

On Tue, 2018-02-27 at 10:22 +, Ramana Radhakrishnan wrote: > The way to fix this in AArch64 if there is a > guarantee from the standard that there are no problems with read-only > locations is to implement the change in libatomic. Even though the standard doesn't specify read-only memory, I

Re: Fw: GCC interpretation of C11 atomics (DR 459)

On Mon, 2018-02-26 at 19:39 +, Ruslan Nikolaev via gcc wrote: > Torvald, I definitely do not want to insist on this design choice, but it > makes sense to at least seriuously consider it given the concerns I > described. And especially because IFFUNC in libatomic already redirects to >

Re: Fw: GCC interpretation of C11 atomics (DR 459)

On Mon, Feb 26, 2018 at 10:45 PM, Ruslan Nikolaev via gcc wrote: > Thanks, everyone, for the output, it is very useful. I am just proposing to > consider the change unless there are clear roadblocks. (Either design choice > is probably OK with respect to the standard formally

Re: GCC interpretation of C11 atomics (DR 459)

On 02/26/2018 07:36 PM, Janne Blomqvist wrote: There is no such architectural guarantee. At least on some micro-architecture (AMD Opteron "Istanbul") it's possible to construct a test which fails, proving that at least on that micro-arch SSE2 load/store isn't guaranteed to be atomic. Looks

[Bug c/84563] GCC interpretation of C11 atomics (DR 459)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84563 --- Comment #2 from Ruslan Nikolaev --- Summary (from the mailing list): Pros of the proposed approach: 1. Ability to use guaranteed lock-free double-width atomics (when mcx16 is specified for x86-64, and always for arm64) in more or less

Re: Fw: GCC interpretation of C11 atomics (DR 459)

Thanks, everyone, for the output, it is very useful. I am just proposing to consider the change unless there are clear roadblocks. (Either design choice is probably OK with respect to the standard formally speaking, but there are some clear advantages also.) I wrote a summary of pros & cons

Re: Fw: GCC interpretation of C11 atomics (DR 459)

Torvald, I definitely do not want to insist on this design choice, but it makes sense to at least seriuously consider it given the concerns I described. And especially because IFFUNC in libatomic already redirects to cmpxchg16b, so it just adds extra cost and indirection. Quite frankly, I do

Re: GCC interpretation of C11 atomics (DR 459)

On Mon, 2018-02-26 at 18:55 +, Ruslan Nikolaev via gcc wrote: > Torvald, thank you for your output. See my response below. > > On Monday, February 26, 2018 1:35 PM, Torvald Riegel > wrote: > > > ... does not imply this latter statement. The statement you cited is

Re: Fw: GCC interpretation of C11 atomics (DR 459)

On Mon, 2018-02-26 at 07:24 +, Ruslan Nikolaev via gcc wrote: > Alexander, > Thank you for your comments. Please see my response below. I definitely do > not want to fight for or against this change in gcc, but there are definitely > legitimate concerns to consider. I think, it would really

Re: GCC interpretation of C11 atomics (DR 459)

Torvald, thank you for your output. See my response below. On Monday, February 26, 2018 1:35 PM, Torvald Riegel wrote: > ... does not imply this latter statement.  The statement you cited is > about what the standard itself requires, not what makes sense for a >

Re: GCC interpretation of C11 atomics (DR 459)

On Mon, 2018-02-26 at 08:50 +0300, Alexander Monakov wrote: > > For these reasons, it may be a good idea if GCC folks reconsider past > > decision. And just to clarify: if mcx16 (x86-64) is not specified during > > compilation, it is totally OK to redirect to libatomic, and there make the > >

Re: GCC interpretation of C11 atomics (DR 459)

On Mon, Feb 26, 2018 at 8:15 PM, Florian Weimer wrote: > On 02/26/2018 05:00 AM, Ruslan Nikolaev via gcc wrote: >> >> If I understand correctly, the redirection to libatomic was made for 2 >> reasons: >> 1. cmpxchg16b is not available on early amd64 processors. (However, mcx16

Re: GCC interpretation of C11 atomics (DR 459)

On Mon, 2018-02-26 at 14:53 +, Ruslan Nikolaev via gcc wrote: > Thank you for more comments, my response is below. > > > > On Mon, 26 Feb 2018, Szabolcs Nagy wrote:> > > rmw load is only valid if the implementation can > > guarantee that atomic objects are never read-only. > But per

Re: GCC interpretation of C11 atomics (DR 459)

On Monday, February 26, 2018 1:15 PM, Florian Weimer wrote: > I think x86-64 should be able to do atomic load and store via SSE2 > registers, but perhaps if the memory is suitably aligned (which is the > other problem—the libatomic code will work irrespective of

Re: GCC interpretation of C11 atomics (DR 459)

On 02/26/2018 05:00 AM, Ruslan Nikolaev via gcc wrote: If I understand correctly, the redirection to libatomic was made for 2 reasons: 1. cmpxchg16b is not available on early amd64 processors. (However, mcx16 flag already specifies that you use CPUs that have this instruction, so it should not

[Bug c/84563] GCC interpretation of C11 atomics (DR 459)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84563 --- Comment #1 from Ruslan Nikolaev --- See also discussion in the gcc mailing list

Re: GCC interpretation of C11 atomics (DR 459)

Thank you for more comments, my response is below. On Mon, 26 Feb 2018, Szabolcs Nagy wrote:> > rmw load is only valid if the implementation can > guarantee that atomic objects are never read-only. But per response from WG14 regarding DR 459 which I quoted, the standard does not seem to

Re: GCC interpretation of C11 atomics (DR 459)

On 26/02/18 13:56, Alexander Monakov wrote: On Mon, 26 Feb 2018, Szabolcs Nagy wrote: rmw load is only valid if the implementation can guarantee that atomic objects are never read-only. OK, but that sounds like a matter of not emitting atomic objects into .rodata, which shouldn't be a big

Re: GCC interpretation of C11 atomics (DR 459)

On Mon, 26 Feb 2018, Szabolcs Nagy wrote: > > rmw load is only valid if the implementation can > guarantee that atomic objects are never read-only. OK, but that sounds like a matter of not emitting atomic objects into .rodata, which shouldn't be a big problem, if not for backwards compatibility

Re: GCC interpretation of C11 atomics (DR 459)

On 26/02/18 04:00, Ruslan Nikolaev via gcc wrote: 1. Not consistent with clang/llvm which completely supports double-width atomics for arm32, arm64, x86 and x86-64 making it possible to write portable code (w/o specific extensions or assembly code) across all these architectures (which is

Re: Fw: GCC interpretation of C11 atomics (DR 459)

> I'd say the main issue is that libatomic is not guaranteed to work like that. > Today it relies on IFUNC for redirection, so you may (and not "will") get the > desired behavior on Glibc (implying Linux), not on other OSes, and neither on > Linux with non-GNU libc (nor on bare metal, for that

Re: Fw: GCC interpretation of C11 atomics (DR 459)

On Mon, 26 Feb 2018, Ruslan Nikolaev via gcc wrote: > Well, if libatomic is already doing it when corresponding CPU feature is > available (i.e., effectively implementing operations using cmpxchg16b), I do > not see any problem here. mcx16 implies that you *have* cmpxchg16b, therefore > other code

Fw: GCC interpretation of C11 atomics (DR 459)

Alexander, Thank you for your comments. Please see my response below. I definitely do not want to fight for or against this change in gcc, but there are definitely legitimate concerns to consider.  I think, it would really be good to consider this change to make things more compatible (i.e., at

Re: GCC interpretation of C11 atomics (DR 459)

Hello, Although I wouldn't like to fight defending GCC's design change here, let me offer a couple of corrections/additions so everyone is on the same page: On Mon, 26 Feb 2018, Ruslan Nikolaev via gcc wrote: > > 1. Not consistent with clang/llvm which completely supports double-width > atomics

[Bug c/84563] New: GCC interpretation of C11 atomics (DR 459)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84563 Bug ID: 84563 Summary: GCC interpretation of C11 atomics (DR 459) Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c

GCC interpretation of C11 atomics (DR 459)

Hi I have read multiple bug reports (84522, 80878, 70490), and the past decision regarding GCC change to redirect double-width (128-bit) atomics for x86-64 and arm64 to libatomic. Below I mention major concerns as well as the response from C11 (WG14) regarding DR 459 which, most likely,