[Development] Qt LTS & C++11 plans

[Thiago Macieira]

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