On 07/07/2022 05.55, Ivan Čukić wrote:
Hi Nicolas,
While I've been known to request newer and newer compilers
for everything, and while I do support this request for GCC 10
and Clang 11, I'm not sure I'd support requiring QCoro and
coroutines.
Not because of QCoro itself, but that clang doesn't yet officially
support coroutines. According to [1] they have a partial support
since version 8, and according to [2] they might lead to problems
when coroutines might be resumed on a wrong thread (if I'm
reading this correctly), with a comment 'This feature requires
further analysis of the C++ Standard to determine what work is
necessary for conformance.'
You might very well not be reading this correctly, as it's phrased very
ambiguously:
The optimizer does not yet handle TLS with __attribute__((const))
attribute correctly. There can be issues where the coroutine may
resume on a different thread.
This feature requires further analysis of the C++ Standard to
determine what work is necessary for conformance.
These three sentences are not describing three unrelated issues. They
should be interpreted as subordinates:
1. Coroutines may interact weirdly with thread-local storage (TLS).
2. The optimizer is normally allowed to cache the result of calls which
are marked __attribute__((const)).
3. If a coroutine resumes from co_await on a different thread, the
cached result of a const function which accesses a TLS variable will be
based on the previous thread
4. "This feature" in the last sentence refers to this rather exotic
interaction of coroutines, thread-local storage and const functions
(which are a GNU extension, not part of the C++ standard).
This bug has a real-world case where this could happen due to
pthread_self() being a const function which accesses TLS to retrieve the
current thread's ID: https://bugs.llvm.org/show_bug.cgi?id=47833
Clang development seems to have slowed down a bit so I'm
not sure how viable is pushing C++20 to Plasma just yet.
Modules, Concepts and Coroutines are huge new features that will take
years to mature.
However, C++20 also brought dozens of smaller language and library
improvements that have been working just fine in both Clang and GCC even
before the C++20 draft was finalized:
https://android-review.googlesource.com/c/platform/system/netd/+/1161045
I don't remember encountering any Clang bugs in 2 years of usage in
AOSP, and it's now enabled in more places:
https://cs.android.com/search?q=cpp_std.*(experimental%7Cc%5C%2B%5C%2B2%5B03a%5D%7Cgnu%5C%2B%5C%2B2%5B03a%5D)%20file:Android.bp
Especially since most of us compile with GCC - if we are able
to overlook bugs that our patches introduce for dark-theme
users because we use and test on the light one, I can't dare
to imagine issues we can introduce to Clang-based distros. :)
Would be good to have CI pipelines building all of KDE with the oldest
officially supported versions of GCC and Clang.
Ok, building and possibly also *testing* ;-)
Cheers,
Ivan
p.s. From a personal standpoint, yes, I'd really like to be able to
use QCoro in Vault...
[1] https://en.cppreference.com/w/cpp/compiler_support/20
[2] https://clang.llvm.org/cxx_status.html
--
_ // Bernie Innocenti
\X/ https://codewiz.org/
