Re: [PATCH] Avoid atomic for guard acquire when that is expensive

2020-12-08 Thread Jason Merrill via Gcc-patches
On 12/7/20 11:17 AM, Bernd Edlinger wrote: On 12/7/20 4:04 PM, Jason Merrill wrote: On 12/5/20 7:37 AM, Bernd Edlinger wrote: On 12/2/20 7:57 PM, Jason Merrill wrote: On 12/1/20 1:28 PM, Bernd Edlinger wrote: +  tree type = targetm.cxx.guard_mask_bit () +  ? TREE_TYPE (guard)

Re: [PATCH] Avoid atomic for guard acquire when that is expensive

2020-12-07 Thread Bernd Edlinger
On 12/7/20 4:04 PM, Jason Merrill wrote: > On 12/5/20 7:37 AM, Bernd Edlinger wrote: >> On 12/2/20 7:57 PM, Jason Merrill wrote: >>> On 12/1/20 1:28 PM, Bernd Edlinger wrote: +  tree type = >>> targetm.cxx.guard_mask_bit () +  ? TREE_TYPE (guard) : char_type_node; +

Re: [PATCH] Avoid atomic for guard acquire when that is expensive

2020-12-07 Thread Jason Merrill via Gcc-patches
On 12/5/20 7:37 AM, Bernd Edlinger wrote: On 12/2/20 7:57 PM, Jason Merrill wrote: On 12/1/20 1:28 PM, Bernd Edlinger wrote: On 11/24/20 11:10 PM, Jason Merrill wrote: On 11/22/20 3:05 AM, Bernd Edlinger wrote: Hi, this avoids the need to use -fno-threadsafe-statics on arm-none-eabi or worki

Re: [PATCH] Avoid atomic for guard acquire when that is expensive

2020-12-05 Thread Bernd Edlinger
T __guard_test_bit (0, 1). Only ARM EABI uses bit 0 in byte 3 if big-endian and bit 0 in byte 0 otherwise. For all other targets when _GLIBCXX_USE_FUTEX is defined, __cxa_guard_XXX accesses the value as int* while the memory is a 64-bit long, so I could imagine that is an aliasing violation.

Re: [PATCH] Avoid atomic for guard acquire when that is expensive

2020-12-02 Thread Jason Merrill via Gcc-patches
On 12/1/20 1:28 PM, Bernd Edlinger wrote: On 11/24/20 11:10 PM, Jason Merrill wrote: On 11/22/20 3:05 AM, Bernd Edlinger wrote: Hi, this avoids the need to use -fno-threadsafe-statics on arm-none-eabi or working around that problem by supplying a dummy __sync_synchronize function which might j

Re: [PATCH] Avoid atomic for guard acquire when that is expensive

2020-12-01 Thread Bernd Edlinger
Instead of a new target macro, can't you follow > fold_builtin_atomic_always_lock_free/can_atomic_load_p? > Yes, thanks, that should work too. Would you like this better? Thanks Bernd. From 863b023786f7e8321979bcdb33c027d37d5e155b Mon Sep 17 00:00:00 2001 From: Bernd Edlinger Date: Tu

Re: [PING] [PATCH] Avoid atomic for guard acquire when that is expensive

2020-11-30 Thread Jason Merrill via Gcc-patches
On 11/30/20 3:08 PM, Bernd Edlinger wrote: Hi, I'd like to ping for this patch: I reviewed it on the 24th: https://gcc.gnu.org/pipermail/gcc-patches/2020-November/560118.html https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559882.html Thanks Bernd. On 11/22/20 9:05 AM, Bernd Edli

[PING] [PATCH] Avoid atomic for guard acquire when that is expensive

2020-11-30 Thread Bernd Edlinger
Hi, I'd like to ping for this patch: https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559882.html Thanks Bernd. On 11/22/20 9:05 AM, Bernd Edlinger wrote: > Hi, > > this avoids the need to use -fno-threadsafe-statics on > arm-none-eabi or working around that problem by supplying > a dum

Re: [PATCH] Avoid atomic for guard acquire when that is expensive

2020-11-24 Thread Jason Merrill via Gcc-patches
On 11/22/20 3:05 AM, Bernd Edlinger wrote: Hi, this avoids the need to use -fno-threadsafe-statics on arm-none-eabi or working around that problem by supplying a dummy __sync_synchronize function which might just lead to silent code failure of the worst kind (non-reproducable, racy) at runtime,

[PATCH] Avoid atomic for guard acquire when that is expensive

2020-11-22 Thread Bernd Edlinger
: [PATCH] Avoid atomic for guard acquire when that is expensive When the atomic access involves a call to __sync_synchronize it is better to call __cxa_guard_acquire unconditionally, since it handles the atomics too, or is a non-threaded implementation when there is no gthread support for this target