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 l
> 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 wouldn't
> 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
2-27 at 13:16 +0000, 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
> 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 m
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 offi
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 (whi
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 not
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
> particular implementation.
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 alignment, as
> far as I und
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 define
> 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 ma
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
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, triggere
14 matches
Mail list logo
