https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89417
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |WONTFIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89417
--- Comment #7 from Jonathan Wakely ---
(In reply to Federico Kircheis from comment #6)
> For what is worth, I imagined the implementation for parameters of different
> type and more or less than two to be similar to
>
>
> template
> auto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89417
--- Comment #6 from Federico Kircheis ---
For what is worth, I imagined the implementation for parameters of different
type and more or less than two to be similar to
template
auto sorted_indexes(Args&... args) {
const void*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89417
--- Comment #5 from Federico Kircheis ---
(In reply to Jonathan Wakely from comment #4)
> (In reply to Federico Kircheis from comment #3)
> > My guess, without having looked at the implementation of std::lock, is that
> > the algorithm uses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89417
--- Comment #4 from Jonathan Wakely ---
(In reply to Federico Kircheis from comment #3)
> My guess, without having looked at the implementation of std::lock, is that
> the algorithm uses try_lock to eventually lock/unlock the mutexes and see if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89417
--- Comment #3 from Federico Kircheis ---
Thank you for the analysis, explanation and references, I did not think about
testing std::lock directly.
I'm still unsure if that means that it is a bug in valgrind, unfortunately I do
not know other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89417
--- Comment #2 from Jonathan Wakely ---
(In reply to Federico Kircheis from comment #0)
> In case helgrind is correct, it seems that there are some issues behind
> std::scoped_lock, since it was explicitly designed for solving issues with
> lock
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89417
Federico Kircheis changed:
What|Removed |Added
Version|8.2.0 |10.1.0
--- Comment #1 from Federico
