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

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:


I don't remember encountering any Clang bugs in 2 years of usage in AOSP, and it's now enabled in more places:


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* ;-)


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/

Reply via email to