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

[Howard Hinnant]

Ok, thanks Richard.  I'll take care of it in libc++.

Howard

On May 20, 2013, at 8:32 PM, Richard Smith <richard at metafoo.co.uk> wrote:

> 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