On Tuesday 23 June 2015 10:17:40 Knoll Lars wrote: > Qt 5.7: > > * New compiler baseline with gcc 4.7 and VC++ 2012 > * Enable and use the C++11 features supported by these compilers > unconditionally
BTW, there's one more C++11 feature I'd like to use unconditionally starting in Qt 5.7: atomics. They've been supported since Clang 3.1, ICC 13.0, GCC 4.7, MSVC 2012. This is needed because our assembly apparently has problems, as in QTBUG-46949 (see especially https://bugreports.qt.io/browse/QTBUG-46949?focusedCommentId=285873#comment-285873 ). I don't want to maintain non-x86 assembly anymore. So here's the plan: * Qt 5.6: will use std::atomic, if available * Qt 5.7: will use std::atomic unconditionally In any case, this is a net improvement: Arch Qt assembly GCC 4.9 atomics All all are lock-free all sizes are supported ARMv5 4-byte only, Linux-only out-of-line, lock-free on Linux ARMv6 4-byte only 4-byte inline, others out-of-line ARMv7A, v7M, v8 all sizes all sizes inline and lock-free IA-64 all sizes all sizes inline and lock-free MIPS32 4-byte only 1 through 4 bytes inline MIPS64 4- and 8-bytes only all sizes inline and lock-free x86 1-4 bytes only all sizes inline and lock-free x86-64 all sizes all sizes inline and lock-free There is no case where the Qt inline, lock-free assembly would be replaced by non-lock-free code. On ARMv5, there's a slight drop in performance as the inline assembly is replaced by an out-of-line function call, that's all. Any architecture not listed above (notably AArch64) is only supported by qatomic_cxx11.h and qatomic_gcc.h, so either this is a no-op for them, or net improvement by supporting more sizes and not doing a full barrier. I've only tested with GCC 4.9. I'm pretty sure support in GCC 4.8 is the same. However, GCC 4.7 is not very good at atomics anywhere except on x86. I don't care. You can easily upgrade to 4.8 to get better (non-full barrier for everything) performance. 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. -- 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
