This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC interpretation of C11 atomics (DR 459)
- From: Janne Blomqvist <blomqvist dot janne at gmail dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: nruslan_devel at yahoo dot com, gcc mailing list <gcc at gcc dot gnu dot org>
- Date: Mon, 26 Feb 2018 20:36:15 +0200
- Subject: Re: GCC interpretation of C11 atomics (DR 459)
- Authentication-results: sourceware.org; auth=none
- References: <1615980330.4453149.1519617655582.ref@mail.yahoo.com> <1615980330.4453149.1519617655582@mail.yahoo.com> <45a88b2b-2e64-58e7-f68b-a1a7511b6528@redhat.com>
On Mon, Feb 26, 2018 at 8:15 PM, Florian Weimer <fweimer@redhat.com> 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
>> flag already specifies that you use CPUs that have this instruction, so it
>> should not be a concern when the flag is specified.)
>> 2. atomic_load on read-only memory.
>
>
> I think x86-64 should be able to do atomic load and store via SSE2
> registers,
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. See
https://stackoverflow.com/questions/7646018/sse-instructions-which-cpus-can-do-atomic-16b-memory-operations/7647825
for more discussion and a testcase.
--
Janne Blomqvist