[Development] QNX and Dinkumware support for constexpr and nullptr

[James McDonnell]

Fixes to 6.6.0 are...unlikely.  But if you let me know what I need to
take/do to re-produce the problem I can try to help out.  Is it just this
particular change or do I need to take all the changes in the
5.7-c++11-atomics topic?

On 2015-10-28, 7:25 AM, "Development on behalf of Knoll Lars"
<development-bounces at qt-project.org on behalf of
Lars.Knoll at theqtcompany.com> wrote:

>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 81Ž2 
>>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
>
>_______________________________________________
>Development mailing list
>Development at qt-project.org
>http://lists.qt-project.org/mailman/listinfo/development