On 24/09/2024 22:20, Maxim Kuvyrkov wrote:
On Sep 25, 2024, at 05:13, Richard Earnshaw (lists) <richard.earns...@arm.com>
wrote:
On 21/09/2024 08:49, ci_not...@linaro.org wrote:
Dear contributor, our automatic CI has detected problems related to your
patch(es). Please find some details below. If you have any questions, please
follow up on linaro-toolchain@lists.linaro.org mailing list, Libera's
#linaro-tcwg channel, or ping your favourite Linaro toolchain developer on the
usual project channel.
We understand that it might be difficult to find the necessary logs or
reproduce the issue locally. If you can't get what you need from our CI within
minutes, let us know and we will be happy to help.
We track this report status in https://linaro.atlassian.net/browse/GNU-1349 ,
please let us know if you are looking at the problem and/or when you have a fix.
In arm-eabi cortex-m23 soft after:
| commit gcc-15-3607-g9a94c8ffdc8b
| Author: Richard Earnshaw <rearn...@arm.com>
| Date: Thu Sep 12 14:24:55 2024 +0100
|
| arm: testsuite: make use of -mcpu=unset/-march=unset
|
| This patch makes use of the new ability to unset the CPU or
| architecture flags on the command line to enable several more tests on
| Arm. It doesn't cover every case and it does enable some tests that
| now fail for different reasons when the tests are no-longer skipped;
| these were failing anyway for other testsuite configurations, so it's
| ... 22 lines of the commit log omitted.
FAIL: 23 regressions: 22 improvements
regressions.sum:
=== gcc tests ===
Running gcc:gcc.target/arm/arm.exp ...
FAIL: gcc.target/arm/scd42-2.c scan-assembler mov[ \t].*272
Running gcc:gcc.target/arm/cmse/cmse.exp ...
FAIL: gcc.target/arm/cmse/mainline/8_1m/bitfield-4.c -mcpu=unset
-march=armv8.1-m.main+fp -mthumb -O2 scan-assembler
lsls\t(r[3-9]|r10|fp|ip), \\1, #1.*blxns\t\\1
FAIL: gcc.target/arm/cmse/mainline/8_1m/bitfield-4.c -mcpu=unset
-march=armv8.1-m.main+fp -mthumb -O2 scan-assembler
lsrs\t(r[3-9]|r10|fp|ip), \\1, #1.*blxns\t\\1
FAIL: gcc.target/arm/cmse/mainline/8_1m/bitfield-4.c -mcpu=unset
-march=armv8.1-m.main+fp -mthumb -O3 -g scan-assembler
lsls\t(r[3-9]|r10|fp|ip), \\1, #1.*blxns\t\\1
FAIL: gcc.target/arm/cmse/mainline/8_1m/bitfield-4.c -mcpu=unset
-march=armv8.1-m.main+fp -mthumb -O3 -g scan-assembler
lsrs\t(r[3-9]|r10|fp|ip), \\1, #1.*blxns\t\\1
... and 19 more entries
improvements.sum:
=== gcc tests ===
Running gcc:gcc.target/arm/cmse/cmse.exp ...
FAIL: gcc.target/arm/cmse/mainline/8_1m/bitfield-4.c -march=armv8.1-m.main+fp
-mthumb -O3 -g scan-assembler lsrs\t(r[3-9]|r10|fp|ip), \\1, #1.*blxns\t\\1
FAIL: gcc.target/arm/cmse/mainline/8_1m/bitfield-4.c -march=armv8.1-m.main+fp
-mthumb -O3 -g scan-assembler lsls\t(r[3-9]|r10|fp|ip), \\1, #1.*blxns\t\\1
FAIL: gcc.target/arm/cmse/mainline/8_1m/bitfield-4.c -march=armv8.1-m.main+fp
-mthumb -O2 scan-assembler lsrs\t(r[3-9]|r10|fp|ip), \\1, #1.*blxns\t\\1
FAIL: gcc.target/arm/cmse/mainline/8_1m/bitfield-4.c -march=armv8.1-m.main+fp
-mthumb -O2 scan-assembler lsls\t(r[3-9]|r10|fp|ip), \\1, #1.*blxns\t\\1
FAIL: gcc.target/arm/cmse/mainline/8_1m/bitfield-6.c -march=armv8.1-m.main+fp
-mthumb -O2 scan-assembler lsrs\t(r[3-9]|r10|fp|ip), \\1, #1.*blxns\t\\1
FAIL: gcc.target/arm/cmse/mainline/8_1m/bitfield-6.c -march=armv8.1-m.main+fp
-mthumb -O2 scan-assembler lsls\t(r[3-9]|r10|fp|ip), \\1, #1.*blxns\t\\1
FAIL: gcc.target/arm/cmse/mainline/8_1m/bitfield-6.c -march=armv8.1-m.main+fp
-mthumb -O3 -g scan-assembler lsrs\t(r[3-9]|r10|fp|ip), \\1, #1.*blxns\t\\1
... and 16 more entries
I can't make any sense of this at all. After hours wasted trying to find the
configuration information from the logs (it's there, but to the inexperienced
user of your reports, it is buried far too deep), I'm still none-the-wiser.
Hi Richard,
Thanks for looking into this. Do send us a quick email if you can't immideatelly find
what you are looking for. As our email says "We understand that it might be
difficult to find the necessary logs or reproduce the issue locally. If you can't get
what you need from our CI within minutes, let us know and we will be happy to help."
Regarding adding configure information to our reports -- we are working on it.
Great. Where do I find the dejagnu target-list information for a run?
ie the site.exp file (or whatever the DEJAGNU environment variable
points at).
All I can see is that things like
FAIL: gcc.target/arm/cmse/mainline/8_1m/bitfield-4.c -march=armv8.1-m.main+fp
-mthumb -O2 scan-assembler lsrs\t(r[3-9]|r10|fp|ip), \\1, #1.*blxns\t\\1
have changed to
FAIL: gcc.target/arm/cmse/mainline/8_1m/bitfield-4.c -mcpu=unset
-march=armv8.1-m.main+fp -mthumb -O2 scan-assembler
lsrs\t(r[3-9]|r10|fp|ip), \\1, #1.*blxns\t\\1
(ie that -mcpu=unset has been added to the test name).
That's not a regression, it's a simple FAIL->FAIL
Yes, that's correct.
Unfortunately, when a FAILed test is renamed, it appears as a new failure in
the result comparison, and it would be difficult to automatically ignore such
failures without adding a significant hole to the comparison logic for actual
new failures to creep into. Just imagine that instead of changing ...
"FAIL: test -march=foo" -> "FAIL: test -mcpu=unset -march=foo"
... you add an additional axis of compilation flags ...
"FAIL: test -march=foo" -> "FAIL: test -mcpu=unset -march=foo" + "FAIL: test
-mcpu=set -march=foo"
... in this case we indeed have a +1 failure.
Could we perhaps use some fuzzy matching with confidence levels in the
reports to help clarify the results? Something with confidence bands
(obviously each base-line failure must only be allowed to match one
under-test failure), but perhaps we could have something like:
Probable test renames (>80% match):
+FAIL: test with option 1
-FAIL: test with option 0
...
Possible test renames (50->80% match):
...
Likely distinct issues (<50% match):
...
results with no match:
...
I'm plucking numbers out of the air here, but something like this would
help clue the reader in to what the run has found so that time isn't
wasted looking for the wrong issue.
R.
Kind regards,
--
Maxim Kuvyrkov
https://www.linaro.org
R.
You can find the failure logs in *.log.1.xz files in
-
https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-thumb_m23_soft_eabi-build/144/artifact/artifacts/00-sumfiles/
The full lists of regressions and improvements as well as configure and make
commands are in
-
https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-thumb_m23_soft_eabi-build/144/artifact/artifacts/notify/
The list of [ignored] baseline and flaky failures are in
-
https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-thumb_m23_soft_eabi-build/144/artifact/artifacts/sumfiles/xfails.xfail
The configuration of this build is:
CI config tcwg_gnu_embed_check_gcc arm-eabi -mthumb -march=armv8-m.base
-mtune=cortex-m23 -mfloat-abi=soft -mfpu=auto
-----------------8<--------------------------8<--------------------------8<--------------------------
The information below can be used to reproduce a debug environment:
Current build :
https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-thumb_m23_soft_eabi-build/144/artifact/artifacts
Reference build :
https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-thumb_m23_soft_eabi-build/143/artifact/artifacts
Reproduce last good and first bad builds:
https://git-us.linaro.org/toolchain/ci/interesting-commits.git/plain/gcc/sha1/9a94c8ffdc8b554a2d95e0101e96830efee58add/tcwg_gnu_embed_check_gcc/master-thumb_m23_soft_eabi/reproduction_instructions.txt
Full commit :
https://github.com/gcc-mirror/gcc/commit/9a94c8ffdc8b554a2d95e0101e96830efee58add
List of configurations that regressed due to this commit :
* tcwg_gnu_embed_check_gcc
** master-thumb_m23_soft_eabi
*** FAIL: 23 regressions: 22 improvements
***
https://git-us.linaro.org/toolchain/ci/interesting-commits.git/plain/gcc/sha1/9a94c8ffdc8b554a2d95e0101e96830efee58add/tcwg_gnu_embed_check_gcc/master-thumb_m23_soft_eabi/details.txt
***
https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-thumb_m23_soft_eabi-build/144/artifact/artifacts
_______________________________________________
linaro-toolchain mailing list -- linaro-toolchain@lists.linaro.org
To unsubscribe send an email to linaro-toolchain-le...@lists.linaro.org
_______________________________________________
linaro-toolchain mailing list -- linaro-toolchain@lists.linaro.org
To unsubscribe send an email to linaro-toolchain-le...@lists.linaro.org
