On Wednesday 08 July 2015 13:42:12 Thiago Macieira wrote: > The only compiler I currently know that will have problems with this is the > Intel compiler on OS X when using libc++ older than Subversion r215305. > Unfortunately, _LIBCPP_VERSION has been at value 1101 since way before that > change. To restore functionality, I will revert > 1b961e8b5d508d054e31c0050f27891606714393 after 5.6 branches off from dev.
Upon further investigation, it turns out that ICC has worked around the libc++ problem since version 15.0 by providing its own std::atomic implementation when __clang__ is defined (probably a mistake and should have been a check for _LIBCPP_VERSION). However, its implementation is broken. I've just reported two bugs against version 16.0 beta. One bug can be easily worked around[1] but the other[2] isn't easy. I've made sure to report that one as a Critical issue, so let's hope there's an update released, fixing the issue, before 5.7 is out. [1] Issue id 6000117277: std::atomic's constructor is missing "constexpr". Note how libc++'s outside of Clang is too (https://llvm.org/bugs/show_bug.cgi?id=24114) [2] Issue id 6000117300: std::atomic<function_pointer> and std::atomic<const T*> fail to compile. Can be fixed by a one-line change, casting to (void*). We hit both cases in QtCore: qlogging.cpp: static QBasicAtomicPointer<void (QtMsgType, const char*)> msgHandler = Q_BASIC_ATOMIC_INITIALIZER(qDefaultMsgHandler); qobject_p.h: QAtomicPointer<const int> argumentTypes; -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development