On 2/15/22 12:08, Thomas Schwinge wrote:
Hi Tom!
On 2022-02-15T11:52:29+0100, Tom de Vries wrote:
On 2/15/22 08:34, Thomas Schwinge wrote:
For my understanding:
Thanks for your explanations!
It is expected that this changes, for example (similar elsewhere)
'nvptx-none/libatomic/store_4_.o
Hi Tom!
On 2022-02-15T11:52:29+0100, Tom de Vries wrote:
> On 2/15/22 08:34, Thomas Schwinge wrote:
>> For my understanding:
Thanks for your explanations!
>> It is expected that this changes, for example (similar elsewhere)
>> 'nvptx-none/libatomic/store_4_.o', to use (a) 'atom.exch' (with a ne
On 2/15/22 08:34, Thomas Schwinge wrote:
Hi Tom!
For my understanding:
On 2022-02-10T10:13:10+0100, Tom de Vries via Gcc-patches
wrote:
The ptx isa specifies (for pre-sm_7x) that atomic operations on shared memory
locations do not guarantee atomicity with respect to normal store instructions
Hi Tom!
For my understanding:
On 2022-02-10T10:13:10+0100, Tom de Vries via Gcc-patches
wrote:
> The ptx isa specifies (for pre-sm_7x) that atomic operations on shared memory
> locations do not guarantee atomicity with respect to normal store instructions
> to the same address.
>
> This can be
Hi,
The ptx isa specifies (for pre-sm_7x) that atomic operations on shared memory
locations do not guarantee atomicity with respect to normal store instructions
to the same address.
This can be fixed by:
- inserting barriers between normal stores and atomic operations to a common
address
- usin