https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98678
--- Comment #12 from John David Anglin <danglin at gcc dot gnu.org> --- Created attachment 58500 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58500&action=edit Hack to fix failure of poll.cc on hppa-unknown-linux-gnu The number of iterations is specific to my current kernel configuration. The code to determine the number of iterations returned inconsistent results. Current kernel config is 1000 Hz (to reduce test time) and stable clock. Here is a typical run: dave@atlas:~/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/testsuite$ ./poll.exe wait_for(0s): 999992ns for 19500 calls, avg 51.2816ns per call wait_until(system_clock minimum): 3999969ns for 19500 calls, avg 205.127ns per call wait_until(steady_clock minimum): 4999961ns for 19500 calls, avg 256.408ns per call wait_until(system_clock epoch): 19499847791ns for 19500 calls, avg 999992ns per call wait_until(steady_clock epoch: 19498848587ns for 19500 calls, avg 999941ns per call wait_for when ready: 999992ns for 19500 calls, avg 51.2816ns per call missed 9 ticks For some reason, I never see missed ticks in "wait_for(0s)". But we almost always miss ticks in "wait_for when ready" (usually 7 to 9). I turned off ntp but this didn't make any significant difference. CLOCK_MONOTONIC behaves similarly to CLOCK_REALTIME with regard to missing ticks.. dave@atlas:~/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/testsuite$ ./ntime CLOCK_REALTIME - "Systemwide realtime clock.": precision: 1000000ns value : -112725112.1719177549 CLOCK_MONOTONIC - "Represents monotonic time. Cannot be set.": precision: 1000000ns value : -112725112.68986 Didn't need to adjust VERIFY conditions. Test times get much longer at 250 and 100 HZ since clock tick depends on HZ.
