Hi Andrew. Well, the builds are done and they're OK. I've added the ability to compare against an explicit release to make checking regressions easier.
4.4 results are here: http://ex.seabright.co.nz/helpers/testcompare/gcc-linaro-4.4-2010.09-1/logs/... http://ex.seabright.co.nz/helpers/testcompare/gcc-linaro-4.4-2010.09-1/logs/... http://ex.seabright.co.nz/helpers/testcompare/gcc-linaro-4.4-2010.09-1/logs/...
i686 and x86_64 have not regressed since 2010.08.
On arm, and ignoring the limits test, 2010.09 adds a failure on gcc.c-torture/compile/991026-2.c. According to the log the run timed out but I can't reproduce it.
4.5 results are here: http://ex.seabright.co.nz/helpers/testcompare/gcc-linaro-4.5-2010.09-0/logs/... http://ex.seabright.co.nz/helpers/testcompare/gcc-linaro-4.5-2010.09-0/logs/... http://ex.seabright.co.nz/helpers/testcompare/gcc-linaro-4.5-2010.09-0/logs/...
i686 has not regressed since 2010.08. x86_64 fails on gcc.target/i386/wmul-1.c, but this is a new tests for new features and are not a regression against 4.5.1.
arm is messier. The following new failures exist:
Vectoriser related: * g++.dg/vect/pr36648.cc scan-tree-dump-times vect "vectorized 1 loops" 1 * g++.dg/vect/pr36648.cc scan-tree-dump-times vect "vectorizing stmts using SLP" 1 * gcc.dg/vect/vect-multitypes-11.c scan-tree-dump-times vect "vectorized 1 loops" 1 * gcc.dg/vect/vect-multitypes-12.c scan-tree-dump-times vect "vectorized 1 loops" 1 * gcc.dg/vect/vect-reduc-dot-s16b.c scan-tree-dump-times vect "vectorized 1 loops" 0 * gcc.dg/vect/vect-reduc-pattern-1a.c scan-tree-dump-times vect "vectorized 1 loops" 0 * gcc.dg/vect/vect-reduc-pattern-1b.c scan-tree-dump-times vect "vectorized 1 loops" 0 * gcc.dg/vect/vect-reduc-pattern-1c.c scan-tree-dump-times vect "vectorized 1 loops" 0 * gcc.dg/vect/vect-reduc-pattern-2a.c scan-tree-dump-times vect "vectorized 1 loops" 0 * gcc.dg/vect/vect-reduc-pattern-2b.c scan-tree-dump-times vect "vectorized 1 loops" 0 * gcc.dg/vect/wrapv-vect-reduc-pattern-2c.c scan-tree-dump-times vect "vectorized 1 loops" 0
Others: * gcc.target/arm/neon-load-df0.c scan-assembler vmov.i32[ \t]+[dD][0-9]+, #0\n * gcc.target/arm/synchronize.c scan-assembler __sync_synchronize
neon-load-df0 is a new test. synchronize.c is an incorrect test as the compiler now correctly uses the dmb instruction.
Your thoughts?
-- Michael
On 13/09/10 00:46, Michael Hope wrote:
Your thoughts?
The only real regressions are the vectorizer tests, and I'm not worried about those because a) They're only missed optimizations, not correctness issues, and b) I know there are also a number of progressions in the vectorizer tests, so what we lose in one place, we win somewhere else. We should find out if the tests are bogus, or there is a real problem - in an ideal world all the tests would pass.
I tested glibc and there were no regressions, so I think we can make the releases safely.
Andrew
linaro-toolchain@lists.linaro.org