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