[Development] INTEGRITY

[Lars Knoll]

On 19 Sep 2019, at 10:41, Mutz, Marc via Development <development at qt-project.org<mailto:development at qt-project.org>> wrote:

On 2019-09-18 17:33, Thiago Macieira wrote:
On Wednesday, 18 September 2019 08:16:46 PDT Giuseppe D'Angelo via Development
wrote:
> We've never required C++11 Standard Library. We've only required the core
> language and the integrity compiler does support it just fine.
Not really, it also fails on constexpr:
https://codereview.qt-project.org/c/qt/qtbase/+/264550
No, it has a bug in its existing constexpr implementation. That's different.
MSVC 2015 officially supported constexpr, but we turned it off for them
because it was too buggy.
Are we sure to be running the latest version of the GHS compiler?
According to INTEGRITY documentation: "Namespace member
std::condition_variable is not supported, along with any library functions
related to it (for example, std::notify_all_at_thread_exit)."
So there's no way out of this.
Seems like it. Like I said, we've never required the C++11 standard library
and we need to be sure the feature we need is supported before we commit to
it.

https://www.qt.io/blog/2016/06/16/qt-5-7-released
"we require a C++11[-]compliant compiler to build [...] Qt"

The std library is not optional, unless you mean that Qt explicitly targets free-standing implementations. That, however, is not mentioned. When we dropped support for pre-C++98-compilers in 5.0, we also removed -no-stl, because that's natural. There's a technical distinction between the compiler and the std library, but from the POV of the standard, in hosted environments, there isn't.

QNX was a case where an older library (by a different vendor) shipped with a newer GCC, and that limited the use of library features in Qt, but that particular platform is now gone, and if Integrity has the same problem as that QNX toolchain had, it should have been removed along with it. Otherwise, we could've kept QNX along for the ride with no extra cost to the Qt project.

I think we should be way past caring for non-conforming platforms. We decided to use SD-6 macros for post-C++14 feature detection, even thought that meant that none of the features were detected for MSVC, a much more important platform that Integrity.

But that didn’t break MSVC. It simply meant that they didn’t get some new features or performance improvements. So there’s a huge difference here.

The worst thing is that INTEGRITY claims support for C++14 on it's homepage, even citing the official name of the standard. It *does* provide std::condition_variable, proven by the fact that the header exists, can be included and use of std::condition_variable is compiled without error, so it's clearly positioning itself as a hosted environment, not a free-standing one. That means that std::condition_variable needs to be available, or else you're non-conforming. If you're advertising with conformance, but are in fact nonconforming, that's misleading advertising, which, at least in EU law, is punishable.

That, and the fact that the pthreads version we're replacing in QWaitCondition was working before, makes me think that there can be no reason not to provide std::condition_variable, because it totally models pthread's condition variables, so either we're using an old version of the tool-chain, or the OS, or we're indeed just missing a linker flag.

But no-one seems to know anything (and there's _still_ no maintainer for the platform listed in the wiki). The best reaction I get is to revert the patch that introduced use of std::condition_variable. If you would have a look at how much complexity is taken out of the Qt implementation of QWaitCondition by simply implementing it on top of the std one, incl. deleting a rather recent change for just Android, it should be obvious how this hurts maintainability of Qt. I know Thiago revels in such details, but there're also those Qt devs who cannot bear the presence of a find_if. What would the latter half have to say about the four or so different mutex implementations? While the mutex implementations can be argued to actually be worth it (though they could be reduced to two: futex and std::mutex), because futex outperforms std::mutex, QWaitCondition is _much_ slower (on Windows an order of magnitude) than std::condition_variable.

Standing in the way of Qt maintainability in this way should disqualify INTEGRITY as a supported platform until it's resolved.

So, I update my requests:

1. List a maintainer for INTEGRITY in https://wiki.qt.io/Maintainers
2. That maintainer should either find the missing linker flag, or file a bug with Integrity
3. If there's a work-around (providing those missing functions in Qt, e.g.), apply it, else

I agree that we should have a named maintainer for the platform.

4. drop Integrity support (or update to a newer version) ASAP (for Qt 5.15 if not 5.14).

This is a bit black and white. You’re proposing to drop all of INTEGRITY because you’re not willing to work around things on that platform for one patch that is in principle a pure cleanup patch doing internal refactoring. It wouldn’t be too difficult (though maybe not very nice looking though) to keep the old code for INTEGRITY only. It’s been tested and we know it works.

We’ve been applying workarounds for missing support for some C++11 features in other toolchains/compilers as well. We kept the Atomic implementations for MSVC around for exactly the same reasons.

Cheers,
Lars

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20190919/bd4cebf1/attachment.html>