Message ID | orzgi59qvw.fsf@lxoliva.fsfla.org |
---|---|
State | New |
Headers | show |
Series | libstdc++: async: tolerate slightly shorter sleep | expand |
On Jun 22, 2022, Alexandre Oliva <oliva@adacore.com> wrote: > Regstrapped on x86_64-linux-gnu, also tested with a cross to > aarch64-rtems6. Ok to install? The early wakeups are fixed for rtems6.1, so the same question raised at https://gcc.gnu.org/pipermail/gcc-patches/2022-June/597102.html apply to this one: libstdc++: xfail nanosleep tests on rtems From: Alexandre Oliva <oliva@adacore.com> Since it has been determined that nanosleep may return slightly too early on RTEMS, due to clock resolution differences, expect 30_thread/async tests that have detected too-early wakeups to fail on RTEMS targets. for libstdc++-v3/ChangeLog * testsuite/30_threads/async/async.cc: xfail on RTEMS. TN: V608-048 --- libstdc++-v3/testsuite/30_threads/async/async.cc | 1 + 1 file changed, 1 insertion(+) diff --git a/libstdc++-v3/testsuite/30_threads/async/async.cc b/libstdc++-v3/testsuite/30_threads/async/async.cc index 38943ff1a9a5e..e0b731186c459 100644 --- a/libstdc++-v3/testsuite/30_threads/async/async.cc +++ b/libstdc++-v3/testsuite/30_threads/async/async.cc @@ -2,6 +2,7 @@ // { dg-additional-options "-pthread" { target pthread } } // { dg-require-effective-target c++11 } // { dg-require-gthreads "" } +// { dg-xfail-if "nanosleep may wake up too early" { *-*-rtems* } } // Copyright (C) 2010-2022 Free Software Foundation, Inc. //
On Thu, 23 Jun 2022 at 12:38, Alexandre Oliva via Libstdc++ <libstdc++@gcc.gnu.org> wrote: > > On Jun 22, 2022, Alexandre Oliva <oliva@adacore.com> wrote: > > > Regstrapped on x86_64-linux-gnu, also tested with a cross to > > aarch64-rtems6. Ok to install? > > The early wakeups are fixed for rtems6.1, so the same question raised at > https://gcc.gnu.org/pipermail/gcc-patches/2022-June/597102.html apply to > this one: Looks like I never reviewed this one, sorry. The patch to xfail this test for rtems is OK. > > libstdc++: xfail nanosleep tests on rtems > > From: Alexandre Oliva <oliva@adacore.com> > > Since it has been determined that nanosleep may return slightly too > early on RTEMS, due to clock resolution differences, expect > 30_thread/async tests that have detected too-early wakeups to fail on > RTEMS targets. > > > for libstdc++-v3/ChangeLog > > * testsuite/30_threads/async/async.cc: xfail on RTEMS. > > TN: V608-048 > --- > libstdc++-v3/testsuite/30_threads/async/async.cc | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/libstdc++-v3/testsuite/30_threads/async/async.cc b/libstdc++-v3/testsuite/30_threads/async/async.cc > index 38943ff1a9a5e..e0b731186c459 100644 > --- a/libstdc++-v3/testsuite/30_threads/async/async.cc > +++ b/libstdc++-v3/testsuite/30_threads/async/async.cc > @@ -2,6 +2,7 @@ > // { dg-additional-options "-pthread" { target pthread } } > // { dg-require-effective-target c++11 } > // { dg-require-gthreads "" } > +// { dg-xfail-if "nanosleep may wake up too early" { *-*-rtems* } } > > // Copyright (C) 2010-2022 Free Software Foundation, Inc. > // > > > -- > Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/ > Free Software Activist GNU Toolchain Engineer > Disinformation flourishes because many people care deeply about injustice > but very few check the facts. Ask me about <https://stallmansupport.org> >
On Wed, 12 Oct 2022 at 12:41, Jonathan Wakely wrote: > > On Thu, 23 Jun 2022 at 12:38, Alexandre Oliva via Libstdc++ > <libstdc++@gcc.gnu.org> wrote: > > > > On Jun 22, 2022, Alexandre Oliva <oliva@adacore.com> wrote: > > > > > Regstrapped on x86_64-linux-gnu, also tested with a cross to > > > aarch64-rtems6. Ok to install? > > > > The early wakeups are fixed for rtems6.1, so the same question raised at > > https://gcc.gnu.org/pipermail/gcc-patches/2022-June/597102.html apply to > > this one: > > Looks like I never reviewed this one, sorry. > > The patch to xfail this test for rtems is OK. It's also fine if you just want to drop this patch for the same reason as https://gcc.gnu.org/pipermail/gcc-patches/2022-June/597105.html (I'm just going through old patch submissions that never got acked or nacked and this was one of them.)
On Oct 12, 2022, Jonathan Wakely <jwakely@redhat.com> wrote: > On Wed, 12 Oct 2022 at 12:41, Jonathan Wakely wrote: >> >> On Thu, 23 Jun 2022 at 12:38, Alexandre Oliva via Libstdc++ >> <libstdc++@gcc.gnu.org> wrote: >> > >> > On Jun 22, 2022, Alexandre Oliva <oliva@adacore.com> wrote: >> > >> > > Regstrapped on x86_64-linux-gnu, also tested with a cross to >> > > aarch64-rtems6. Ok to install? >> > >> > The early wakeups are fixed for rtems6.1, so the same question raised at >> > https://gcc.gnu.org/pipermail/gcc-patches/2022-June/597102.html apply to >> > this one: >> >> Looks like I never reviewed this one, sorry. >> >> The patch to xfail this test for rtems is OK. > It's also fine if you just want to drop this patch for the same reason > as https://gcc.gnu.org/pipermail/gcc-patches/2022-June/597105.html Yeah, nanosleep is fixed, no need for this one, thanks, withdrawn.
diff --git a/libstdc++-v3/testsuite/30_threads/async/async.cc b/libstdc++-v3/testsuite/30_threads/async/async.cc index 38943ff1a9a5e..b151677af6a0e 100644 --- a/libstdc++-v3/testsuite/30_threads/async/async.cc +++ b/libstdc++-v3/testsuite/30_threads/async/async.cc @@ -104,7 +104,8 @@ void test03() VERIFY( status == std::future_status::ready ); auto const elapsed = CLOCK::now() - start; - VERIFY( elapsed >= std::chrono::seconds(2) ); + auto const tolerance = std::chrono::milliseconds(6); + VERIFY( elapsed + tolerance >= std::chrono::seconds(2) ); VERIFY( elapsed < std::chrono::seconds(5) ); } @@ -169,7 +170,8 @@ void test_pr91486_wait_for() auto status = f1.wait_for(wait_time); auto const elapsed_steady = chrono::steady_clock::now() - start_steady; - VERIFY( elapsed_steady >= std::chrono::seconds(1) ); + auto const tolerance = std::chrono::milliseconds(3); + VERIFY( elapsed_steady + tolerance >= std::chrono::seconds(1) ); } // This is a clock with a very recent epoch which ensures that the difference @@ -222,7 +224,8 @@ void test_pr91486_wait_until() auto const elapsed_steady = chrono::steady_clock::now() - start_steady; // This checks that we didn't come back too soon - VERIFY( elapsed_steady >= std::chrono::seconds(1) ); + auto const tolerance = std::chrono::milliseconds(3); + VERIFY( elapsed_steady + tolerance >= std::chrono::seconds(1) ); // This checks that wait_until didn't busy wait checking the clock more times // than necessary.