On Tue, Sep 6, 2016 at 8:26 AM, Jakub Jelinek <ja...@redhat.com> wrote: > On Tue, Sep 06, 2016 at 08:14:58AM -0400, Nathan Sidwell wrote: >> On 09/06/16 06:57, David Edelsohn wrote: >> >> >What about Jakub's comment in the PR? >> > >> >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77378#c6 >> >> This needs addressing. Can you clarify PPC behaviour, because I may have >> misunderstood: >> >> 1) PPC currently has 64 bit counters -- but cannot support 64bit atomic ops >> in 32 bit mode. >> >> 2) PPC currently has 32 bit counters anyway. >> >> I had interpreted the comment to be implying #2, but now I'm not so sure. > > Aren't the counters 64-bit everywhere? > Even with 32-bit atomics, as the only operation needed is addition, can't it > be implemented anyway? Instead of: > __atomic_fetch_add_8 (&val, 1, __ATOMIC_RELAXED); > one could for e.g. little endian: > if (__atomic_add_fetch_4 ((unsigned int *) &val, 1, __ATOMIC_RELAXED) == 0) > __atomic_fetch_add_4 (((unsigned int *) &val) + 1, 1, __ATOMIC_RELAXED);
Is this correct for either endianness? - David > There is a small risk that e.g. SIGTERM happens in between the two and the > counters are written into the file without the upper half being bumped, but > compared to the non-atomic updates it is much less likely (and, if you > actually never overflow the counters, it won't be an issue anyway). > > Jakub
