[Bug middle-end/65093] New: [5 Regression] 26_numerics/random/binomial_distribution/operators/values.cc times out

[Bug middle-end/65093] New: [5 Regression] 26_numerics/random/binomial_distribution/operators/values.cc times out

[hp at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65093

            Bug ID: 65093
           Summary: [5 Regression]
                    26_numerics/random/binomial_distribution/operators/val
                    ues.cc times out
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: hp at gcc dot gnu.org
              Host: x86_64-linux-gnu
            Target: cris-elf

This test used to pass.  Since a commit in the range (220738:220744]it fails
for cris-elf as follows:

Running
/tmp/hpautotest-gcc1/gcc/libstdc++-v3/testsuite/libstdc++-dg/conformance.exp
...
[...]

WARNING: program timed out.
FAIL: 26_numerics/random/binomial_distribution/operators/values.cc execution
test

(no further information in the .log file)

There were no changes to libstdc++-v3 in the revision range.  Apparently the
middle-end changed such that code quality suffered enough that the test now
times out on the machine where I run autototests.  I'm going to bisect the
middle-end changes in the revision range and inspect the code.

[Bug middle-end/65093] [5 Regression] 26_numerics/random/binomial_distribution/operators/values.cc times out

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65093

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |5.0

[Bug middle-end/65093] [5 Regression] 26_numerics/random/binomial_distribution/operators/values.cc times out

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65093

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P4
                 CC|                            |jakub at gcc dot gnu.org

[Bug testsuite/65093] 26_numerics/random/binomial_distribution/operators/values.cc times out on slow targets

[hp at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65093

Hans-Peter Nilsson <hp at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|middle-end                  |testsuite
           Assignee|unassigned at gcc dot gnu.org      |hp at gcc dot gnu.org
            Summary|[5 Regression]              |26_numerics/random/binomial
                   |26_numerics/random/binomial |_distribution/operators/val
                   |_distribution/operators/val |ues.cc times out on slow
                   |ues.cc times out            |targets

--- Comment #1 from Hans-Peter Nilsson <hp at gcc dot gnu.org> ---
I was wrong, this is not a regression, and certainly not between the listed
revisions on trunk.

For r220738, the number of cycles (using --cris-cycles=all) counts as
43001142008.
For r220744, the number is 42824445951, i.e. actually about ~0.4% improvement.
(Still the same number for r220792.)

Checking for general regression on trunk doesn't check out either: omparing to
the 4.9 branch, where I have not seen this test-case fail, I get for r220707,
47526792666 cycles.  Hence the trunk is still 10% better.  (Very very nice; I
suspect work done on trunk for libstdc++ random numbers is the anonymous hero.)

Incidentally, the machine where the trunk autotester runs has a recently
increased workload (but not *that* correlated to the perceived regression) and
is generally slower than the machine where the 4.9 branch is autotested. 
Applying "time" shows close to 10 minutes runtime for the test-case on the
"trunk machine" and I see 8:52.16 for the "4.9 machine".

In summary, there is no regression but certainly an issue that the test-case is
unfriendly to slow targets and there's reason to split it up, not the least
since it appears to consist of five different subtests and is easily split up. 
I'm taking the bug to see if that's accepted.

(It's just odd that no FAIL has been observed before, as the test itself hasn't
changed for quite some time, like 1.5 year since the last two
camel-back-breaking subtests were added.)

[Bug testsuite/65093] 26_numerics/random/binomial_distribution/operators/values.cc times out on slow targets

[hp at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65093

--- Comment #2 from Hans-Peter Nilsson <hp at gcc dot gnu.org> ---
Author: hp
Date: Thu Feb 19 19:30:03 2015
New Revision: 220821

URL: https://gcc.gnu.org/viewcvs?rev=220821&root=gcc&view=rev
Log:
    PR testsuite/65093
    * testsuite/26_numerics/random/binomial_distribution/operators/values.cc
    (test01): Add explanatory comment.  Keep only the bd1 sub-test and
    split out bd2, bd3, bd4, and bd5 sub-tests into...
    * testsuite/26_numerics/random/binomial_distribution/operators/values2.cc,
    testsuite/26_numerics/random/binomial_distribution/operators/values3.cc,
    testsuite/26_numerics/random/binomial_distribution/operators/values4.cc,
    testsuite/26_numerics/random/binomial_distribution/operators/values5.cc:
    New separate files with the old parts.

Added:
   
trunk/libstdc++-v3/testsuite/26_numerics/random/binomial_distribution/operators/values2.cc
   
trunk/libstdc++-v3/testsuite/26_numerics/random/binomial_distribution/operators/values3.cc
   
trunk/libstdc++-v3/testsuite/26_numerics/random/binomial_distribution/operators/values4.cc
   
trunk/libstdc++-v3/testsuite/26_numerics/random/binomial_distribution/operators/values5.cc
Modified:
    trunk/libstdc++-v3/ChangeLog
   
trunk/libstdc++-v3/testsuite/26_numerics/random/binomial_distribution/operators/values.cc

[Bug testsuite/65093] 26_numerics/random/binomial_distribution/operators/values.cc times out on slow targets

[hp at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65093

Hans-Peter Nilsson <hp at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |FIXED

--- Comment #3 from Hans-Peter Nilsson <hp at gcc dot gnu.org> ---
(In reply to Hans-Peter Nilsson from comment #1)
> (It's just odd that no FAIL has been observed before, as the test itself
> hasn't changed for quite some time, like 1.5 year since the last two
> camel-back-breaking subtests were added.)

The test was enabled relatively recently for my autotesters, for the 4.9 branch
as late as 2014-12-17 (c:a r218800) and for trunk about 2015-02-15 (c:a
r220715).  This happened automatically.  The cause is most probably an update
of newlib, to a version with the pieces missing for dg-require-cstdint or
dg-require-cmath to be true.  Automatic updates only happen when the branch is
regression-free and only if the results after a tentative update would still be
regression-free.  There's no specific log event for tests that pass after an
update.