gnu /
gcc /
8e2a1096b0e83200c9dd58cdcd472dce05afb825 From what I understand of the libstdc++/83237 thread at
<https://gcc.gnu.org/ml/gcc-patches/2017-12/msg00573.html>, the
high numbers are not arbitrary, so it seems wrong to try
lowering them, or we'd just waste cycles testing nothing, or
worse, ending up with a bogus error indication. Better to just
plain disable this part of the test for simulator targets; I
assume the results should be the same on any IEEE-float target,
i.e. no target-specific things going on here that'd raise a need
to cover it everywhere.
With this part of the test disabled, I saw the test finishing in
(time) "124.74s user" where it was before "1120.26s user"
running the cris-elf-run simulator on a "i7-4770K CPU @ 3.50GHz"
host. Most certainly that indidates that the remainder of the
test is still too much for *some* host+simulator combos, but I'm
happy with the runtime lowered to 1/5 of the timeout (10
minutes) on this particular combination, and I'd think this
fixes timeouts for many other simulator combos too.
This construct (disabling or lowering limits for simulators) is
used elsewhere in the libstdc++ test-suite and in particular the
SIMULATOR_TEST macro is used in the testsuite machinery (though
AFAICT not in testDiscreteDist).
* testsuite/26_numerics/random/poisson_distribution/operators/values.cc:
Don't run the libstdc++/83237 part on simulator targets.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@271574 138bc75d-0d04-0410-961f-82ee72b054a4
2 files changed
