Martin Wille wrote:
Vladimir Prus wrote:
The test fails with that looks like ICE:
Martin, could you run this test by hand and tell if this indeed compiler issue, and not some "out of memory/out of disk" condition?
If this is compiler issue, I don't think we need to bother looking for workaround for gcc-3.4.5, and can mark this failure as expected. I don't even thing that reporting this to gcc developers makes sense -- given that this compiler version is rather old.
This is a case of excessive use of CPU time :)
The compiler is limited to 30 minutes by the wrapper script I use.
Compiling operators test has been consuming a lot of CPU over a long time and for several versions of gcc. I'm not surprised it hits the limit now.
Given the number of compilers that are affected, it is likely that the problem is in the code being compiled.
For me, with gcc-4.0.3, the test compiles rather quickly. What is the time for other compilers?
I do not want to remove the limit. It serves as a firewall against tests running wild (we used to have a lot of them). So this limit helps a lot in running tests unattended.
I certainly agree that if a test runs out of 30 min limit, it's a problem with the test, not your setup. Not too mention that spending 30 min on a single test throttles the testsuite turnaround time. Is anybody in position to work on fixing this? - Volodya