[cfe-dev] libc++: help diagnosing the following std::atomic compile error

[Richard Smith]

This is a weird behavior of gcc's built-in, which clang faithfully emulates.
On 20 May 2013 17:07, "Howard Hinnant" <hhinnant at apple.com> wrote:

> Clang or libc++ bug for __atomic_fetch_add using pointer types?
>
> #include <atomic>
> #include <iostream>
>
> template <class T>
> T
> simulated_atomic_fetch_add(T* ptr, ptrdiff_t val, int)
> {
>     T tmp = *ptr;
>     *ptr += val;
>     return tmp;
> }
>
> int
> main()
> {
>     int* p = nullptr;
>     __atomic_fetch_add(&p, 1, __ATOMIC_RELAXED);
>     std::cout << (void*)p << '\n';
>     p = nullptr;
>     simulated_atomic_fetch_add(&p, 1, __ATOMIC_RELAXED);
>     std::cout << (void*)p << '\n';
> }
>
> 0x1
> 0x4
>
> I.e. __atomic_fetch_add (and __atomic_fetch_sub) assumes the pointer is a
> pointer to char.
>
> I can fix this in libc++, or should it be fixed in clang?  The "official"
> spec at:
>
> http://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html
>
> is sloppy, and doesn't clarify.  I'm happy to do whatever gcc is doing,
> and I have no idea what that is.
>
> Howard
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130520/2d94be66/attachment.html>