[Development] QNX and Dinkumware support for constexpr and nullptr

[Thiago Macieira]

On Tuesday 27 October 2015 16:40:07 Thiago Macieira wrote:
> The check for certain defines indicates that there are versions of DW with
> the  necessary support. Are those available for QNX 6.6 toolchains?
> 
> If so, how soon can the CI be upgraded to those toolchains?
> 
> If not, we'll have to make some hard decisions.

Ground rule: if there's no information from QNX experts and cooperation in 
timely fashion to *fix* the issues, the CI will disable QNX testing. Fixing 
the breakages becomes a problem assigned to people interested in supporting 
Dinkumware (I'm not). If all else fails, our QNX support can advise people to 
drop DW and use libstdc++.

Note especially that the C++11 support requirements were extensively discussed 
in June, so this is not news. Anyone with a vested interest in a platform 
should have tested against those requirements soon after QtCS and reported any 
issues in the thread. Silence was consent.

Decision tree:

1) if there is a toolchain with support for nullptr, constexpr, and <atomic>, 
the CI will be upgraded to use it and that will become the minimum toolchain 
release for QNX 6.6.

2) if not but QNX is able to release an update in the next couple of months, 
we should disable QNX in the CI now and reenable it after the toolchain is 
released, requiring it from everyone.

On <atomic>:

A3) if not (if the constexpr methods in the Standard Library are missing) but 
the toolchain supports <atomic> with its constexpr methods, I can fix the 
header. Constexpr is not a mandatory feature outside of QAtomicInteger.

A4) if there's no QNX toolchain that supports <atomic> anytime soon, but the 
GCC compiler backend is GCC 4.7 or later, I can bring back qatomic_gcc.h and 
upgrade it with the atomic primitive intrinsics so that we get std::atomic 
level of support.

A5) if not, then I can bring back qatomic_gcc.h as it is in Qt 5.6, which uses 
the old __sync intrinsics. This will have the side-effect of always using full 
barriers/fence on both ARM and x86 (and that's totally unnecessary for x86), 
thus introducing a performance impact. This impact serves as an added 
incentive for QNX to provide a C++11 compliant Standard Library soon. There's 
no option to keep the current assembly.

On nullptr:

N3) if there's no Dinkumware version that defines std::nullptr_t but the GCC 
compiler backend is GCC 4.6 or later, we can easily do:
	namespace std { typedef decltype(nullptr) nullptr_t; }
and attempt to survive: we can probably live with the Standard Library missing 
std::nullptr_t overloads.

N4) if the compiler backend is too old, then QNX support needs to be dropped 
until the upgrade comes along.

<rant>
Qt 5.7 will be released 5 years after the C++11 standard was ratified and 8½ 
years after the paper introducing introducing <atomic> was published (N2427). 
It's bad enough that we need to support one major implementation that fails to 
have proper support in the compiler they released in 2015 (Microsoft) and they 
really, really should be ashamed. Please don't make another platform level 
itself down to the worst of the compilers we have to support.

Especially when the problems are the result out of a choice: the choice to 
remove libstdc++ that came with the compiler and use an inferior solution.
</rant>

PS: dinkumware.com says "The makers of the STL library included in Microsoft's 
VC.". Yeah, I guess that explains a lot.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center