From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 2B8383861037; Sun, 23 Jun 2024 21:22:06 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2B8383861037 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1719177726; bh=7zXhXKzEpiuxWc/AIl+CrvSaoSJOnww2aaggDdGlb+E=; h=From:To:Subject:Date:In-Reply-To:References:From; b=bG/n3+SWXGpXaAAT3h3GlazTNExFbKeC+O7HvdbUyaobEe1q92jEGLoay1bKZVHFa zUW+dx+RK38pRXhR9Owiuwx/31s3dmG1IWlxyyowUEcNnQXLYjasuDojtS+qbuq2MP iWGoPtnDYVtSiSOxYtZfRoSPAj9hc+vkkqUqfclY= From: "danglin at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/98678] 30_threads/future/members/poll.cc execution test FAILs Date: Sun, 23 Jun 2024 21:22:03 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: libstdc++ X-Bugzilla-Version: 11.0 X-Bugzilla-Keywords: testsuite-fail X-Bugzilla-Severity: normal X-Bugzilla-Who: danglin at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 11.5 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D98678 --- Comment #12 from John David Anglin --- Created attachment 58500 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=3D58500&action=3Dedit Hack to fix failure of poll.cc on hppa-unknown-linux-gnu The number of iterations is specific to my current kernel configuration. T= he 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.e= xe 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 behav= es 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= .=