On 25/11/20 01:07 +0000, Jonathan Wakely wrote:
On 24/11/20 23:45 +0000, Jonathan Wakely wrote:
On 21/11/20 16:36 -0800, H.J. Lu wrote:
On Sat, Nov 21, 2020 at 9:40 AM Jonathan Wakely via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
On 21/11/20 17:04 +0000, Jonathan Wakely wrote:
On 21/11/20 16:16 +0100, Andreas Schwab wrote:
In file included from
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/shared_ptr_atomic.h:33,
from
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/memory:78,
from
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/m68k-linux/bits/stdc++.h:82,
from
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/m68k-linux/bits/extc++.h:32,
from
/daten/aranym/gcc/gcc-20201121/libstdc++-v3/testsuite/17_intro/headers/c++2020/all_attributes.cc:37:
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/atomic_base.h:
In member function 'void std::atomic_flag::wait(bool, std::memory_order)
const':
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/atomic_base.h:239:
error: no matching function for call to '__atomic_wait(const __atomic_flag_data_type*,
bool&, std::atomic_flag::wait(bool, std::memory_order) const::<lambda()>)'
In file included from
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/atomic_base.h:41,
from
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/shared_ptr_atomic.h:33,
from
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/memory:78,
from
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/m68k-linux/bits/stdc++.h:82,
from
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/m68k-linux/bits/extc++.h:32,
from
/daten/aranym/gcc/gcc-20201121/libstdc++-v3/testsuite/17_intro/headers/c++2020/all_attributes.cc:37:
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/atomic_wait.h:265:
note: candidate: 'template<class _Tp, class _Pred> void
std::__atomic_wait(const _Tp*, _Tp, _Pred)'
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/atomic_wait.h:265:
note: template argument deduction/substitution failed:
In file included from
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/shared_ptr_atomic.h:33,
from
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/memory:78,
from
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/m68k-linux/bits/stdc++.h:82,
from
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/m68k-linux/bits/extc++.h:32,
from
/daten/aranym/gcc/gcc-20201121/libstdc++-v3/testsuite/17_intro/headers/c++2020/all_attributes.cc:37:
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/atomic_base.h:239:
note: deduced conflicting types for parameter '_Tp' ('unsigned char' and
'bool')
I'm testing this.
I'm committing this instead, it's the same but also disables
29_atomics/atomic/wait_notify/generic.cc on non-linux targets.
Tested sparc-solaris2.11 and powerpc64le-linux.
There are still some timeouts on linux:
FAIL: 30_threads/latch/3.cc execution test
FAIL: 30_threads/semaphore/try_acquire_for.cc execution test
I opened:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97936
I've disabled the failing tests for now. They can be re-enabled after
the problem is found and fixed.
I was finally able to reproduce the hangs, and I think this is the
fix:
--- a/libstdc++-v3/include/bits/atomic_wait.h
+++ b/libstdc++-v3/include/bits/atomic_wait.h
@@ -100,9 +100,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
auto __e = syscall (SYS_futex, static_cast<const void*>(__addr),
static_cast<int>(__futex_wait_flags::__wait_private),
__val, nullptr);
- if (!__e)
+ if (!__e || errno == EAGAIN)
break;
- else if (!(errno == EINTR || errno == EAGAIN))
+ else if (errno != EINTR)
__throw_system_error(__e);
}
}
The problem is that we're going into a busy loop when SYS_futex
returns EAGAIN, but that means the current value doesn't match the
expected value, so we should return not keep waiting for the value to
change.
I've pushed that as ad9cbcee543ecccd79fa49dafcd925532d2ce210 but there
are still other FAILs to be fixed.
