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: unassig...@gcc.gnu.org
ReportedBy: h...@gcc.gnu.org
CC: fdum...@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.
