[Development] QNX and Dinkumware support for constexpr and nullptr

[Knoll Lars]

Hi Thiago,

Removing QNX support is not an option; we agreed at the contributor summit that QNX 6.6 is part of the baseline, just as much as VS 2012 is. So if that toolchain has some issues, we’ll need to work around them just as for some other platforms.

In fact, we have always been and will always have to deal with workarounds for certain platforms or compilers. This is nothing new, and looking at your comments below, we can work around the issues without too much trouble.






On 28/10/15 01:52, "Development on behalf of Thiago Macieira" <development-bounces at qt-project.org on behalf of thiago.macieira at intel.com> wrote:

>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.

No, then we’ll see if we can have workarounds for the platform. Given that the toolchain uses gcc 4.7 this should be possible without too much hassle. Constexpr is a pure compiler feature, so that should work.
>
>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.

Choose your poison here. I’d simply add add a configure test for full <atomic> support, and if it fails fall back to A5.
>
>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.

N3 should probably work, let’s give it a try.
>
><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>

This is nothing new. We also have to support VC6 for many years, even though it’s C++98 support was pretty damn broken. 

To me, it look like the problems can be worked around in a pragmatic way that doesn’t hinder us on the other platforms in any major way.

Cheers,
Lars