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,
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
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
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
> 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
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
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
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
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
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
>
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
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
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
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
> 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
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
16 matches
Mail list logo