[Bug libstdc++/51386] New: [4.7 Regression]: 23_containers/unordered_set/hash_policy/load_factor.cc execution timeout

["hp at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51386

             Bug #: 51386
           Summary: [4.7 Regression]:
                    23_containers/unordered_set/hash_policy/load_factor.cc
                    execution timeout
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: hp@gcc.gnu.org
                CC: fdumont@gcc.gnu.org
              Host: x64_86-unknown-linux-gnu
            Target: cris-axis-elf


With revision r181675 this test passed.
>From revision r181679 and on, this test has failed as follows:

Running
/tmp/hpautotest-gcc1/gcc/libstdc++-v3/testsuite/libstdc++-dg/conformance.exp
...
WARNING: program timed out.
FAIL: 23_containers/unordered_set/hash_policy/load_factor.cc execution test

With the message in the logfile being uninteresting:

PASS: 23_containers/unordered_set/hash_policy/load_factor.cc (test for excess
errors)
WARNING: program timed out.
FAIL: 23_containers/unordered_set/hash_policy/load_factor.cc execution test

The timeout is 10 minutes.
Author of patches in suspect revision range CC:ed.

Note: cris-elf is tested as a simulator target, the host is a Core2 Duo E8400 @
3GHz.

The load_factor.cc test itself has iterations with numbers like 100000 which
seem like they should be lowered for simulator targets just as is done for
other tests.  But, the timeout is a red flag; it seems one or more of the
changes in the revision-range pessimized the library performance-wise.  All the
suspect changes ones are to libstdc++-v3 itself.  Without a timeout, that test
take more than 25 minutes after the changes.  I'll add a new comment with the
measured time some time after the test has finished.