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-boun...@qt-project.org on behalf of lars.kn...@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-boun...@qt-project.org on behalf of >thiago.macie...@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@qt-project.org >http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development