public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Alexandre Oliva <oliva@adacore.com>
To: gcc-patches@gcc.gnu.org, libstdc++@gcc.gnu.org
Subject: [PATCH] [libstdc++] [testsuite] require cmath for [PR114359]
Date: Thu, 13 Jun 2024 04:27:02 -0300	[thread overview]
Message-ID: <or4j9xgv5l.fsf@lxoliva.fsfla.org> (raw)


When !_GLIBCXX_USE_C99_MATH_TR1, binomial_distribution doesn't use the
optimized algorithm that was fixed in response to PR114359.  Without
that optimized algorithm, operator() ends up looping very very long
for the test, to the point that it would time out by several orders of
magnitude, without even exercising the optimized algorithm that we're
testing for regressions.  Arrange for the test to be skipped if that
bit won't be exercised.

Regstrapped on x86_64-linux-gnu, also tested with gcc-13
x-aarch64-rtems6, where the problem was detected.  Ok to install?


for  libstdc++-v3/ChangeLog

	PR libstdc++/114359
	* testsuite/26_numerics/random/binomial_distribution/114359.cc:
	Require cmath.
---
 .../random/binomial_distribution/114359.cc         |   13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/libstdc++-v3/testsuite/26_numerics/random/binomial_distribution/114359.cc b/libstdc++-v3/testsuite/26_numerics/random/binomial_distribution/114359.cc
index c1e4c380bf91d..12d967dcbfd34 100644
--- a/libstdc++-v3/testsuite/26_numerics/random/binomial_distribution/114359.cc
+++ b/libstdc++-v3/testsuite/26_numerics/random/binomial_distribution/114359.cc
@@ -2,6 +2,19 @@
 
 // Bug 114359 - std::binomial_distribution hangs in infinite loop
 
+// { dg-require-cmath "" }
+
+// The requirement above is not strictly true.  The test should work
+// without cmath, and it probably does, but without cmath,
+// binomial_distribution::operator() skips the optimized algorithm and
+// calls _M_waiting to loop a gazillion times.  On aarch64-rtems6
+// qemu, that loop takes over 5 minutes to go through a small fraction
+// of the iteration space (__x at 22k, limited at 1G; __sum at 2e-5,
+// limited at 0.69).  The bug we're regression-testing here was in the
+// cmath-requiring bit, so even if this could conceivably not time out
+// on a really fast machine, there's hardly any reason to exercise
+// this extreme case.
+
 #include <random>
 
 int main()

-- 
Alexandre Oliva, happy hacker            https://FSFLA.org/blogs/lxo/
   Free Software Activist                   GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive

             reply	other threads:[~2024-06-13  7:27 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-13  7:27 Alexandre Oliva [this message]
2024-06-13 10:41 ` Jonathan Wakely
2024-06-13 11:01   ` EXT: " Chen, Yee Men (GE Vernova)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=or4j9xgv5l.fsf@lxoliva.fsfla.org \
    --to=oliva@adacore.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=libstdc++@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).