Re: [Linaro-TCWG-CI] gcc-15-3575-gc07cf418fdde: FAIL: 2 regressions on master-thumb_m0_eabi
On Mon, 30 Sept 2024 at 07:22, 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-1358 , please let us know if you are looking at the problem and/or when you have a fix.
In arm-eabi cortex-m0 soft after:
| commit gcc-15-3575-gc07cf418fdde | Author: Jonathan Wakely jwakely@redhat.com | Date: Tue Sep 10 14:25:41 2024 +0100 | | libstdc++: std::string move assignment should not use POCCA trait [PR116641] | | The changes to implement LWG 2579 (r10-327-gdb33efde17932f) made | std::string::assign use the propagate_on_container_copy_assignment | (POCCA) trait, for consistency with operator=(const basic_string&). | ... 18 lines of the commit log omitted.
FAIL: 2 regressions
regressions.sum: | === libstdc++ tests === | | Running libstdc++:libstdc++-dg/conformance.exp ... | FAIL: 21_strings/basic_string/allocator/116641.cc -std=gnu++17 (test for excess errors) | UNRESOLVED: 21_strings/basic_string/allocator/116641.cc -std=gnu++17 compilation failed to produce executable | | # "FAIL" means : the execution of the compiled binary failed / output of the binary differs from the expected one
You can find the failure logs in *.log.1.xz files in
=== libstdc++ Summary ===
# of expected passes 6036 # of unexpected failures 4689 <<< !!!
Is that normal for this configuration?!
The new testcase fails for the same reason as the 4000 other tests:
/home/tcwg-buildslave/workspace/tcwg_gnu_0/abe/builds/destdir/x86_64-pc-linux-gnu/arm-eabi/bin/ld: (__deregister_frame_info): Unknown destination type (ARM/Thumb) in /home/tcwg-buildslave/workspace/tcwg_gnu_0/abe/builds/x86_64-pc-linux-gnu/arm-eabi/gcc-gcc.git~master-stage2/./gcc/crtbegin.o crtstuff.c:(.text+0x5e): dangerous relocation: unsupported relocation
So I don't think this is a problem in the commit, I think it's just a configuration that isn't well supported.
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=armv6s-m -mtune=cortex-m0 -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_m0_eabi-bui... Reference build : https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-thumb_m0_eabi-bui...
Instruction to reproduce the build : https://git-us.linaro.org/toolchain/ci/interesting-commits.git/plain/gcc/sha...
Full commit : https://github.com/gcc-mirror/gcc/commit/c07cf418fdde0c192e370a8d76a991cc721...
On Mon, 30 Sept 2024 at 10:49, Jonathan Wakely via Gcc-regression gcc-regression@gcc.gnu.org wrote:
On Mon, 30 Sept 2024 at 07:22, 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-1358 , please let us know if you are looking at the problem and/or when you have a fix.
In arm-eabi cortex-m0 soft after:
| commit gcc-15-3575-gc07cf418fdde | Author: Jonathan Wakely jwakely@redhat.com | Date: Tue Sep 10 14:25:41 2024 +0100 | | libstdc++: std::string move assignment should not use POCCA trait [PR116641] | | The changes to implement LWG 2579 (r10-327-gdb33efde17932f) made | std::string::assign use the propagate_on_container_copy_assignment | (POCCA) trait, for consistency with operator=(const basic_string&). | ... 18 lines of the commit log omitted.
FAIL: 2 regressions
regressions.sum: | === libstdc++ tests === | | Running libstdc++:libstdc++-dg/conformance.exp ... | FAIL: 21_strings/basic_string/allocator/116641.cc -std=gnu++17 (test for excess errors) | UNRESOLVED: 21_strings/basic_string/allocator/116641.cc -std=gnu++17 compilation failed to produce executable | | # "FAIL" means : the execution of the compiled binary failed / output of the binary differs from the expected one
You can find the failure logs in *.log.1.xz files in
=== libstdc++ Summary ===# of expected passes 6036 # of unexpected failures 4689 <<< !!!
Is that normal for this configuration?!
The new testcase fails for the same reason as the 4000 other tests:
/home/tcwg-buildslave/workspace/tcwg_gnu_0/abe/builds/destdir/x86_64-pc-linux-gnu/arm-eabi/bin/ld: (__deregister_frame_info): Unknown destination type (ARM/Thumb) in /home/tcwg-buildslave/workspace/tcwg_gnu_0/abe/builds/x86_64-pc-linux-gnu/arm-eabi/gcc-gcc.git~master-stage2/./gcc/crtbegin.o crtstuff.c:(.text+0x5e): dangerous relocation: unsupported relocation
So I don't think this is a problem in the commit, I think it's just a configuration that isn't well supported.
Indeed. This error was caused by a linker patch of mine, which I've now fixed. The CI detected the problem before I pushed my fixed and saw the new test failing, and reported it as a regression (it has no way of guessing it's actually a problem with the linker).
That being said, we normally start bisection with "new" master branch (instead of "current" master as of when the regression was detected), in case it has been fixed between when it was detected and when bisect actually starts. In this case, I think we had a huge backlog of regressions to bisect because of my incorrect linker patch, which took time to recover.
Thanks for checking!
Christophe
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=armv6s-m -mtune=cortex-m0 -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_m0_eabi-bui... Reference build : https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-thumb_m0_eabi-bui...
Instruction to reproduce the build : https://git-us.linaro.org/toolchain/ci/interesting-commits.git/plain/gcc/sha...
Full commit : https://github.com/gcc-mirror/gcc/commit/c07cf418fdde0c192e370a8d76a991cc721...
On Mon, 30 Sept 2024 at 15:36, Christophe Lyon christophe.lyon@linaro.org wrote:
On Mon, 30 Sept 2024 at 10:49, Jonathan Wakely via Gcc-regression gcc-regression@gcc.gnu.org wrote:
On Mon, 30 Sept 2024 at 07:22, 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-1358 , please let us know if you are looking at the problem and/or when you have a fix.
In arm-eabi cortex-m0 soft after:
| commit gcc-15-3575-gc07cf418fdde | Author: Jonathan Wakely jwakely@redhat.com | Date: Tue Sep 10 14:25:41 2024 +0100 | | libstdc++: std::string move assignment should not use POCCA trait [PR116641] | | The changes to implement LWG 2579 (r10-327-gdb33efde17932f) made | std::string::assign use the propagate_on_container_copy_assignment | (POCCA) trait, for consistency with operator=(const basic_string&). | ... 18 lines of the commit log omitted.
FAIL: 2 regressions
regressions.sum: | === libstdc++ tests === | | Running libstdc++:libstdc++-dg/conformance.exp ... | FAIL: 21_strings/basic_string/allocator/116641.cc -std=gnu++17 (test for excess errors) | UNRESOLVED: 21_strings/basic_string/allocator/116641.cc -std=gnu++17 compilation failed to produce executable | | # "FAIL" means : the execution of the compiled binary failed / output of the binary differs from the expected one
You can find the failure logs in *.log.1.xz files in
=== libstdc++ Summary ===# of expected passes 6036 # of unexpected failures 4689 <<< !!!
Is that normal for this configuration?!
The new testcase fails for the same reason as the 4000 other tests:
/home/tcwg-buildslave/workspace/tcwg_gnu_0/abe/builds/destdir/x86_64-pc-linux-gnu/arm-eabi/bin/ld: (__deregister_frame_info): Unknown destination type (ARM/Thumb) in /home/tcwg-buildslave/workspace/tcwg_gnu_0/abe/builds/x86_64-pc-linux-gnu/arm-eabi/gcc-gcc.git~master-stage2/./gcc/crtbegin.o crtstuff.c:(.text+0x5e): dangerous relocation: unsupported relocation
So I don't think this is a problem in the commit, I think it's just a configuration that isn't well supported.
Indeed. This error was caused by a linker patch of mine, which I've now fixed.
Aha, I didn't know if they were longstanding failures or just recent ones.
The CI detected the problem before I pushed my fixed and saw the new test failing, and reported it as a regression (it has no way of guessing it's actually a problem with the linker).
Gotcha - it's a new failure caused by my patch, so identifying it as a separate regression is of course "correct" in general.
That being said, we normally start bisection with "new" master branch (instead of "current" master as of when the regression was detected), in case it has been fixed between when it was detected and when bisect actually starts. In this case, I think we had a huge backlog of regressions to bisect because of my incorrect linker patch, which took time to recover.
Ouch :-)
Thanks for the explanations.
Thanks for checking!
Christophe
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=armv6s-m -mtune=cortex-m0 -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_m0_eabi-bui... Reference build : https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-thumb_m0_eabi-bui...
Instruction to reproduce the build : https://git-us.linaro.org/toolchain/ci/interesting-commits.git/plain/gcc/sha...
Full commit : https://github.com/gcc-mirror/gcc/commit/c07cf418fdde0c192e370a8d76a991cc721...
linaro-toolchain@lists.linaro.org
-
Christophe Lyon -
Jonathan Wakely