boost.atomic misbehaves with Apple clang version 4.1 and -O2

[Andreas Beisler <ebfx@…>]

There seems to be an issue, when assigning to an atomic in a "while (true)" loop (without break statement!).

#include <boost/atomic.hpp>

void this_works()
{
    boost::atomic_bool b(false);
    std::cout << b << std::endl; // 0
    b = true;
    std::cout << b << std::endl; // 1
}

void this_works_too()
{
    boost::atomic_bool b(false);
    while (true)
    {
        std::cout << b << std::endl; // 0
        b = true;
        std::cout << b << std::endl; // 1
        break;
    }
}

void this_doesnt_work()
{
    boost::atomic_bool b(false);
    while (true)
    {
        std::cout << b << std::endl; // 0
        b = true;
        std::cout << b << std::endl; // 0
    }
}

// Issue arises when compiled with Apple LLVM 4.1 and -O2:
//     clang++ -O2 main.cpp

int main(int argc, char ** argv)
{
    this_works();
    this_works_too();
    this_doesnt_work();
    return 0;
}

This happens only when the optimization level is set to at least 2. It happens in clang++ 4.1, but works in clang++ 3.2. Maybe it's possible to work around that issue, since std::atomic works fine.

Best regards, Andreas

[timblechmann]

being a compiler bug, i'd strongly suggest to file a bug report at your compiler vendor, not at the library that triggers the bug.

[Andreas Beisler <ebfx@…>]

Yes, that makes sense, but I was still hoping that there might be a fix to make it work with clang++ 4.1 before boost.atomic is officially released. After all, this version of clang++ is the standard compiler in Xcode for a while now... I will file a bug report at the compiler vendor, too. Thanks.

[timblechmann]

fyi, mentioning this issue at the #llvm irc, the reply was: if clang-3.2 works, it appears to be fixed ...

no idea of their policy of backporting fixes to releases ... one might work around the issue by doing a completely different implementation of atomic for clang, using compiler intrinsics instead of inline assembly ...

[Andreas Beisler <ebfx@…>]

Ah, my bad. I tested Apple clang 4.1 (which is based on clang 3.1) and someone in the #boost irc channel replied that it was working in 'clang 3.2'. I thought he was talking about Apple clang 3.2 and that it was a regression.

So, slight mix-up with the versions on my side. It's all good then.

Thanks for your time!

[anonymous]

'apple clang' != 'clang' ... both have different version numbers ...

[timblechmann]

closing it as wontfix. if someone provides a patch to work around this compiler bug, please reopen.