https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91486
--- Comment #15 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Alexandre Oliva <aol...@gcc.gnu.org>: https://gcc.gnu.org/g:410061b15a9b0a464c851173fa568e49c85570dc commit r15-3385-g410061b15a9b0a464c851173fa568e49c85570dc Author: Alexandre Oliva <ol...@adacore.com> Date: Mon Sep 2 11:31:59 2024 -0300 [libstdc++] [testsuite] avoid async.cc loss of precision [PR91486] When we get to test_pr91486_wait_until(), we're about 10s past the float_steady_clock epoch. This is enough for the 1s delta for the timeout to come out slightly lower when the futex-less wait_until converts the deadline from float_steady_clock to __clock_t. So we may wake up a little too early, and end up looping one extra time to sleep for e.g. another 954ns until we hit the deadline. Each iteration calls float_steady_clock::now(), bumping the call_count that we VERIFY() at the end of the subtest. Since we expect at most 3 calls, and we're going to have at the very least 3 on futex-less targets (one in the test proper, one before wait_until_impl to compute the deadline, and one after wait_until_impl to check whether the deadline was hit), any such imprecision that causes an extra iteration will reach 5 and cause the test to fail. Initializing the epoch in the beginning of the test makes such spurious fails due to loss of precision far less likely. I don't suppose allowing for an extra couple of calls would be desirable. While at that, I'm annotating unused status variables as such. for libstdc++-v3/ChangeLog PR libstdc++/91486 * testsuite/30_threads/async/async.cc (test_pr91486_wait_for): Mark status as unused. (test_pr91486_wait_until): Likewise. Initialize epoch later.
