On 24/09/2024 22:20, Maxim Kuvyrkov wrote:
On Sep 25, 2024, at 05:13, Richard Earnshaw (lists) Richard.Earnshaw@arm.com wrote:
On 21/09/2024 08:49, ci_notify@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 rearnsha@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
The full lists of regressions and improvements as well as configure and make commands are in
The list of [ignored] baseline and flaky failures are in
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_ea... Reference build : https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-thumb_m23_soft_ea... Reproduce last good and first bad builds: https://git-us.linaro.org/toolchain/ci/interesting-commits.git/plain/gcc/sha... Full commit : https://github.com/gcc-mirror/gcc/commit/9a94c8ffdc8b554a2d95e0101e96830efee... 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/sha... *** https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-thumb_m23_soft_ea...
linaro-toolchain mailing list -- linaro-toolchain@lists.linaro.org To unsubscribe send an email to linaro-toolchain-leave@lists.linaro.org