Re: limits-fndefn.c and timeouts
Michael Hope writes: > limits-fndefn.c takes an impressively long time to run. On an idle > machine, -O3 -g -c takes 17:31 and -O2 -g -c takes The test already > has a dg-timeout-factor of 4 giving a total timeout of 20 minutes. > > Removing the -g brings this down to 30 s. Keeping the -g and adding > -fno-var-tracking brings this down to 45 s. > > We could bump the multiplier up to 8 but it's getting a bit > ridiculous. I agree. > Any thoughts? I remember Mark made a convincing case that these sorts of test don't belong in the main testsuite. They add to people's testing time but (a) don't represent real testcases and (b) aren't going to be affected by the vast majority of patches. And whether they pass or not depends as much on how much virtual memory is available as much as anything else. I think the idea was that they would be moved to a different testsuite that is only run on demand. Then (hopefully) regular automatic testers like H.J.'s would run this extra testsuite too. But I don't think a consensus was ever reached... Richard ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
How to install an ARM cross compiler
Saw this, thought it might be interesting if we want to point people at it something in future http://playterm.org/r/install-an-arm-cross-compiler-1316950150 Maybe we could record some more detailed stuff ourselves? Andrew ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: limits-fndefn.c and timeouts
On Tue, Oct 11, 2011 at 8:54 PM, Richard Sandiford wrote: > Michael Hope writes: >> limits-fndefn.c takes an impressively long time to run. On an idle >> machine, -O3 -g -c takes 17:31 and -O2 -g -c takes The test already >> has a dg-timeout-factor of 4 giving a total timeout of 20 minutes. >> >> Removing the -g brings this down to 30 s. Keeping the -g and adding >> -fno-var-tracking brings this down to 45 s. >> >> We could bump the multiplier up to 8 but it's getting a bit >> ridiculous. > > I agree. > >> Any thoughts? > > I remember Mark made a convincing case that these sorts of test don't > belong in the main testsuite. They add to people's testing time but > (a) don't represent real testcases and (b) aren't going to be affected > by the vast majority of patches. And whether they pass or not depends > as much on how much virtual memory is available as much as anything else. > > I think the idea was that they would be moved to a different testsuite > that is only run on demand. Then (hopefully) regular automatic testers > like H.J.'s would run this extra testsuite too. But I don't think a > consensus was ever reached... OK. We'll check but generally accept any changes in limit test results. Separately, does this show a performance problem with var tracking? Turning on var tracking leads to a 20 x slow down in this particular case. -- Michael ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Binary toolchain questions summary
Here's my summary from Monday's meeting on the harder parts of binary toolchains. Using a 4.6 compiler against a 4.5 based sysroot such as Natty: * libgcc and libstdc++ are part of the compiler * The compiler expects features that are in the corresponding runtime * You can't reliably run or validate against an earlier runtime The solution is to upgrade the runtime on the sysroot to 4.6. 4.6 is backwards compatible. Ubuntu did this with Maverick and it caused no problems, although problems such as Debian #622783 have been seen. Multiarch: * The Ubuntu multiarch patch should work with a sysroot * Multiarch and multilib should work together Multilib: * The current ARM multilib rules are old and not very relevant * Multilib means you need multiple sysroots as well * Skip multilib for the first release Other: * Anything we support in cross we should support native first * Check that we don't have to directly supply the source that goes with the binary sysroot -- Michael ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
