Richard Sandiford <rdsandif...@googlemail.com> writes: > Sorry HJ, I got your message just after committing. > > "H.J. Lu" <hjl.to...@gmail.com> writes: >> Please try your patch on Linux/ia32 with go enabled. There is >> one go test which runs for a long time: >> >> 8149 hjl 20 0 49388 40m 9.8m R 99.3 0.3 15:18.35 go1 >> >> and it is still running. > > Are you sure this new? I can see long tests in libgo too, but the ones > I looked at were because of long var-tracking times: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54507 > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54402 > > If it is new, which test has got worse?
FWIW, I tried reverting all my patches from yesterday and then bootstrapped on ia32. My results were similar to Uros's: the libgo reflect test took 46m 40s to compile, but without var tracking it took 20s. I checked that the compile time without var tracking was still 20s after reapplying my patches, and that the patches didn't affect the asm output. Richard
