Hi Christophe,
On Tue, Oct 23, 2018 at 03:25:55PM +0200, Christophe Lyon wrote:
On Tue, 23 Oct 2018 at 14:29, Segher Boessenkool
<segher@kernel.crashing.org> wrote:
On Tue, Oct 23, 2018 at 12:14:27PM +0200, Christophe Lyon wrote:
I have noticed many regressions on arm and aarch64 between 265366 and
265408 (this commit is 265398).
I bisected at least one to this commit on aarch64:
FAIL: gcc.dg/ira-shrinkwrap-prep-1.c scan-rtl-dump ira "Split
live-range of register"
The same test also regresses on arm.
Many targets also fail gcc.dg/ira-shrinkwrap-prep-2.c; these tests fail
when random things in the RTL change, apparently.
This is PR87708 now.
For a whole picture of all the regressions I noticed during these two
commits, have a look at:
http://people.linaro.org/~christophe.lyon/cross-validation/gcc/trunk/265408/report-build-info.html
No thanks. I am not going to click on 111 links and whatever is behind
those. Please summarise, like, what was the diff in test_summary, and
then dig down into individual tests if you want. Or whatever else works
both for you and for me. This doesn't work for me.
OK.... this is not very practical for me either. There were 25 commits between
the two validations being compared,
25-28 gcc tests regressed on aarch64, depending on the exact target
177-206 gcc tests regressed on arm*, 7-29 gfortran regressions on arm*
so I could have to run many bisects to make sure every regression is
caused by the same commit.
So many, ouch! I didn't realise.
Since these are all automated builds with everything discarded after
computing the regressions, it's quite time consuming to re-run the
tests manually on my side (probably at least as much as it is for you).
Running arm tests is very painful for me. But you say this is on aarch64
as well, I didn't realise that either; aarch64 should be easy to test,
we have many reasonable aarch64 machines in the cfarm.
I know this doesn't answer your question, but I thought you could run aarch64
tests easily and that would be more efficient for the project that you
do it directly
without waiting for me to provide hardly little more information.
Well, I'm not too familiar with aarch64, so if you can say "this Z is a
pretty simple test that should do X but now does Y" that would be a huge
help :-)
Maybe this will answer your question better:
List of aarch64-linux-gnu regressions:
http://people.linaro.org/~christophe.lyon/cross-validation/gcc/trunk/265408/aarch64-none-linux-gnu/diff-gcc-rh60-aarch64-none-linux-gnu-default-default-default.txt
List of arm-none-linux-gnueabihf regressions:
(gcc) http://people.linaro.org/~christophe.lyon/cross-validation/gcc/trunk/265408/arm-none-linux-gnueabihf/diff-gcc-rh60-arm-none-linux-gnueabihf-arm-cortex-a9-neon-fp16.txt
(gfortran) http://people.linaro.org/~christophe.lyon/cross-validation/gcc/trunk/265408/arm-none-linux-gnueabihf/diff-gfortran-rh60-arm-none-linux-gnueabihf-arm-cortex-a9-neon-fp16.txt
That may help yes, thanks!
To me it just highlights again that we need a validation system easier to
work with when we break something on a target we are not familiar with.
OTOH a patch like this is likely to break many target-specific tests, and
that should not prevent commiting it imnsho. If it actively breaks things,
then of course it shouldn't go in as-is, or if it breaks bootstrap, etc.
I run post-commit validations as finely grained as possible with the CPU
resources I have access to, that's not enough and I think having a
developer-accessible gerrit+jenkins-like system would be very valuable
to test patches before commit. We have a prototype in Linaro, not
production-ready. But I guess that would be worth another
discussion thread :)
Yeah... One when people have time for it ;-)
Segher