> On Jan 25, 2024, at 04:08, ci_notify(a)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(a)lists.linaro.org mailing list, Libera's #linaro-tcwg channel, or ping your favourite Linaro toolchain developer on the usual project channel.
>
> We appreciate 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-1120 , please let us know if you are looking at the problem and/or when you have a fix.
>
> In gdb_check master-arm after:
>
> | commit gdb-14-branchpoint-1354-g8669a8b6740
> | Author: Guinevere Larsen <blarsen(a)redhat.com>
> | Date: Thu Aug 24 11:00:35 2023 +0200
> |
> | gdb/testsuite: add test for backtracing for threaded inferiors from a corefile
> |
> | This patch is based on an out-of-tree patch that fedora has been
> | carrying for a while. It tests if GDB is able to properly unwind a
> | threaded program in the following situations:
> | * regular threads
> | * in a signal handler
> | ... 14 lines of the commit log omitted.
>
> FAIL: 2 regressions
>
> regressions.sum:
> === gdb tests ===
>
> Running gdb:gdb.threads/threadcrash.exp ...
> FAIL: gdb.threads/threadcrash.exp: test_gcore: $thread_count == 7
> FAIL: gdb.threads/threadcrash.exp: test_gcore: $thread_count == [llength $test_list]
Hi Guinevere,
The failures seem to be due to "LWP" output (instead of "Thread") in test_gcore.
I.e., test_corefile succeeds with
===
(gdb) PASS: gdb.threads/threadcrash.exp: test_corefile: loading_corefile
info threads
Id Target Id Frame
* 1 Thread 0xf7dbe7e0 (LWP 476389) 0x00830cea in crash_function () at /home/tcwg-buildslave/workspace/tcwg_gnu_4/abe/snapshots/gdb.git~master/gdb/testsuite/gdb.threads/threadcrash.c:381
2 Thread 0xf7c6f3a0 (LWP 476390) do_spin_task (location=NORMAL) at /home/tcwg-buildslave/workspace/tcwg_gnu_4/abe/snapshots/gdb.git~master/gdb/testsuite/gdb.threads/threadcrash.c:139
3 Thread 0xf746e3a0 (LWP 476391) do_spin_task (location=SIGNAL_HANDLER) at /home/tcwg-buildslave/workspace/tcwg_gnu_4/abe/snapshots/gdb.git~master/gdb/testsuite/gdb.threads/threadcrash.c:139
4 Thread 0xf6c6d3a0 (LWP 476392) do_spin_task (location=SIGNAL_ALT_STACK) at /home/tcwg-buildslave/workspace/tcwg_gnu_4/abe/snapshots/gdb.git~master/gdb/testsuite/gdb.threads/threadcrash.c:139
5 Thread 0xf52fe3a0 (LWP 476395) __libc_do_syscall () at ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:46
6 Thread 0xf646c3a0 (LWP 476393) __libc_do_syscall () at ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:46
7 Thread 0xf5aff3a0 (LWP 476394) __libc_do_syscall () at ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:46
(gdb) PASS: gdb.threads/threadcrash.exp: test_corefile: $thread_count == 7
===
and then test_gcore fails with
===
(gdb) PASS: gdb.threads/threadcrash.exp: test_gcore: loading_corefile
info threads
Id Target Id Frame
* 1 LWP 476440 0x00400cea in crash_function () at /home/tcwg-buildslave/workspace/tcwg_gnu_4/abe/snapshots/gdb.git~master/gdb/testsuite/gdb.threads/threadcrash.c:381
2 LWP 476442 do_spin_task (location=NORMAL) at /home/tcwg-buildslave/workspace/tcwg_gnu_4/abe/snapshots/gdb.git~master/gdb/testsuite/gdb.threads/threadcrash.c:139
3 LWP 476443 do_spin_task (location=SIGNAL_HANDLER) at /home/tcwg-buildslave/workspace/tcwg_gnu_4/abe/snapshots/gdb.git~master/gdb/testsuite/gdb.threads/threadcrash.c:139
4 LWP 476444 do_spin_task (location=SIGNAL_ALT_STACK) at /home/tcwg-buildslave/workspace/tcwg_gnu_4/abe/snapshots/gdb.git~master/gdb/testsuite/gdb.threads/threadcrash.c:139
5 LWP 476445 0xf7eadb04 in ?? ()
6 LWP 476446 0xf7eadb04 in ?? ()
7 LWP 476447 0xf7eadb04 in ?? ()
(gdb) FAIL: gdb.threads/threadcrash.exp: test_gcore: $thread_count == 7
===
Could you please look into fixing the testcase? [I assume "LWP" output is expected, but I'm not an expert in GDB.]
Thanks!
--
Maxim Kuvyrkov
https://www.linaro.org
>
> === Results Summary ===
>
> You can find the failure logs in *.log.1.xz files in
> - https://ci.linaro.org/job/tcwg_gdb_check--master-arm-build/726/artifact/art… .
> The full lists of regressions and progressions are in
> - https://ci.linaro.org/job/tcwg_gdb_check--master-arm-build/726/artifact/art… .
> The list of [ignored] baseline and flaky failures are in
> - https://ci.linaro.org/job/tcwg_gdb_check--master-arm-build/726/artifact/art… .
>
> The configuration of this build is:
> CI config tcwg_gdb_check master-arm
>
> -----------------8<--------------------------8<--------------------------8<--------------------------
> The information below can be used to reproduce a debug environment:
>
> Current build : https://ci.linaro.org/job/tcwg_gdb_check--master-arm-build/726/artifact/art…
> Reference build : https://ci.linaro.org/job/tcwg_gdb_check--master-arm-build/724/artifact/art…
>
> Reproduce last good and first bad builds: https://git-us.linaro.org/toolchain/ci/interesting-commits.git/plain/gdb/sh…
>
> Full commit : https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=8669a8b67408c…
>
> List of configurations that regressed due to this commit :
> * tcwg_gdb_check
> ** master-arm
> *** FAIL: 2 regressions
> *** https://git-us.linaro.org/toolchain/ci/interesting-commits.git/plain/gdb/sh…
> *** https://ci.linaro.org/job/tcwg_gdb_check--master-arm-build/726/artifact/art…
Progress:
* UM-2 [QEMU upstream maintainership]
- patch review:
+ v4 of the raspi-4 SoC/board model series (this is a big one)
+ bug in calculation of limit address in designware pci controller model
+ imx7 serial device: implementation of FIFO and ageing timer
+ patchset to reduce size of fdt blob
- started looking at some of my old device/bus reset cleanup patches,
since another dev on-list was running into a potential issue that
they might help to solve. Failed to repro the test failure that was
the reason I put them on the back burner, so sent them out to the
list as-is...
* QEMU-598 [Model the MPS3-AN536 dual-Cortex-R52 FPGA image]
- updated the SCC device to handle the AN536 specifics (most
actual behaviour will be unimplemented, as we do for our other
board models that have this device)
- checked that we don't need to make any changes to the ioregs
device; the existing model is flexible enough we can configure
it to match the AN536 specifics
- wrote the initial skeleton of the board model (which only creates
the RAM and ROM regions for the moment)
- realized that it might be better to wait for Philippe's reworking
of hw/cpu/a15mpcore.c and friends before adding another similar
object for the Cortex-R52
thanks
-- PMM
Hi H.J.,
Did the email below made it to your inbox? I wonder if some of our precommit CI emails are not reaching developers.
Kind regards,
--
Maxim Kuvyrkov
https://www.linaro.org
> On Jan 10, 2024, at 02:24, ci_notify(a)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(a)lists.linaro.org mailing list, Libera's #linaro-tcwg channel, or ping your favourite Linaro toolchain developer on the usual project channel.
>
> We appreciate 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.
>
> In gcc_check master-arm after:
>
> | gcc patch https://patchwork.sourceware.org/patch/83662
> | Author: H.J. Lu <hjl.tools(a)gmail.com>
> | Date: Tue Jan 9 08:46:59 2024 -0800
> |
> | hwasan: Check if Intel LAM_U57 is enabled
> |
> | When -fsanitize=hwaddress is used, libhwasan will try to enable LAM_U57
> | in the startup code. Update the target check to enable hwaddress tests
> | if LAM_U57 is enabled. Also compile hwaddress tests with -mlam=u57 on
> | x86-64 since hwasan requires LAM_U57 on x86-64.
> |
> | ... 3 lines of the commit log omitted.
> | ... applied on top of baseline commit:
> | 9f7afa99c67 [committed] Adding missing prototype for __clzhi2 to xstormy port
>
> FAIL: 8 regressions
>
> regressions.sum:
> === g++ tests ===
>
> Running g++:g++.dg/hwasan/hwasan.exp ...
> ERROR: can't read "target_hwasan_flags": no such variable
> ERROR: tcl error code TCL LOOKUP VARNAME target_hwasan_flags
> ERROR: tcl error sourcing g++.dg/hwasan/hwasan.exp.
> UNRESOLVED: testcase g++.dg/hwasan/hwasan.exp' aborted due to Tcl error
> === gcc tests ===
>
> Running gcc:gcc.dg/hwasan/hwasan.exp ...
> ... and 6 more entries
>
> You can find the failure logs in *.log.1.xz files in
> - https://ci.linaro.org/job/tcwg_gcc_check--master-arm-precommit/5612/artifac… .
> The full lists of regressions and progressions are in
> - https://ci.linaro.org/job/tcwg_gcc_check--master-arm-precommit/5612/artifac… .
> The list of [ignored] baseline and flaky failures are in
> - https://ci.linaro.org/job/tcwg_gcc_check--master-arm-precommit/5612/artifac… .
>
> The configuration of this build is:
> CI config tcwg_gcc_check master-arm
>
> -----------------8<--------------------------8<--------------------------8<--------------------------
> The information below can be used to reproduce a debug environment:
>
> Current build : https://ci.linaro.org/job/tcwg_gcc_check--master-arm-precommit/5612/artifac…
> Reference build : https://ci.linaro.org/job/tcwg_gcc_check--master-arm-build/1542/artifact/ar…
Thanks for the notification! I took a look and the error seems to be
something specific to the TLS implementation for ARM requiring
additional flags to link correctly, maybe?
I'm unable to test locally (I don't have access to an ARM machine) but
from looking at other testsuite examples which make use of thread
locals, adding the following two lines to the testcases may resolve the
failures:
// { dg-add-options tls }
// { dg-require-effective-target tls_runtime }
Please let me know if the issue is something else and I can take
another look.
Yours,
Nathaniel.
On Thu, Jan 18, 2024 at 07:12:12AM +0000, ci_notify(a)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(a)lists.linaro.org mailing list, Libera's #linaro-tcwg channel, or ping your favourite Linaro toolchain developer on the usual project channel.
>
> We appreciate 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-1112 , please let us know if you are looking at the problem and/or when you have a fix.
>
> In master-arm_eabi after:
>
> | commit gcc-14-8168-g14338386970
> | Author: Nathaniel Shead <nathanieloshead(a)gmail.com>
> | Date: Thu Jan 11 16:49:39 2024 +1100
> |
> | c++: Support thread_local statics in header modules [PR113292]
> |
> | Currently, thread_locals in header modules cause ICEs. This patch makes
> | the required changes for them to work successfully.
> |
> | This requires additionally writing the DECL_TLS_MODEL for thread-local
> | variables to the module interface, and the TLS wrapper function needs to
> | ... 24 lines of the commit log omitted.
>
> FAIL: 3 regressions
>
> regressions.sum:
> === g++ tests ===
>
> Running g++:g++.dg/modules/modules.exp ...
> FAIL: g++.dg/modules/pr113292 -std=c++17 link
> FAIL: g++.dg/modules/pr113292 -std=c++2a link
> FAIL: g++.dg/modules/pr113292 -std=c++2b link
>
> === Results Summary ===
>
> You can find the failure logs in *.log.1.xz files in
> - https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-arm_eabi-build/5… .
> The full lists of regressions and progressions are in
> - https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-arm_eabi-build/5… .
> The list of [ignored] baseline and flaky failures are in
> - https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-arm_eabi-build/5… .
>
> The configuration of this build is:
> CI config tcwg_gnu_embed_check_gcc master-arm_eabi
>
> -----------------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-arm_eabi-build/5…
> Reference build : https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-arm_eabi-build/5…
>
> Reproduce last good and first bad builds: https://git-us.linaro.org/toolchain/ci/interesting-commits.git/plain/gcc/sh…
>
> Full commit : https://github.com/gcc-mirror/gcc/commit/14338386970bc6c2d46b81181f48622fdf…
>
> List of configurations that regressed due to this commit :
> * tcwg_gnu_embed_check_gcc
> ** master-arm_eabi
> *** FAIL: 3 regressions
> *** https://git-us.linaro.org/toolchain/ci/interesting-commits.git/plain/gcc/sh…
> *** https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-arm_eabi-build/5…
Hi
So, I have a ci fail email, and it seems likely to be a valid complaint -
but the reproduce instructions do not work on my platform (bash is not new enough)
and also do not work on cfarm186 (../jenkins-scripts/jenkins-helpers.sh: line 1762: ts: command not found)
For the record, the patch that is flagged as failing *was* tested on aarch64-linux-gnu (cfarm185)
So, I am trying to figure out if the target is different, or some other configure argument.
.. but I cannot work out the failing configure line at present - nor can I see a place to download the console log from the actual failing GCC build (which would presumably have that configure line).
any help much appreciated.
Iain
Hi,
I received an error reported by CI for my patchs, I would like to ask
how I have to reproduce it locally? I looked at the logs and didn't find
the way how it compiles. Thanks in advance.
On 2023/11/8 16:59, ci_notify(a)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(a)lists.linaro.org mailing list, Libera's #linaro-tcwg channel, or ping your favourite Linaro toolchain developer on the usual project channel.
>
> In gcc_build master-arm after:
>
> | 7 patches in gcc
> | Patchwork URL: https://patchwork.sourceware.org/patch/79366
> | ef64c12c9f0 lra: Support subreg live range track and conflict detect
> | a871f544e2b lra: Apply live_subreg df_problem to lra pass
> | 6437747d6f3 ira: Add all nregs >= 2 pseudos to tracke subreg list
> | 1a2da1ad5f0 ira: Support subreg copy
> | 4f8d8e764e0 ira: Support subreg live range track
> | ... and 2 more patches in gcc
> | ... applied on top of baseline commit:
> | ca281a7b971 [i386] APX: Fix ICE due to movti postreload splitter [PR112394]
>
> Results changed to
> # reset_artifacts:
> -10
> # true:
> 0
> # build_abe gcc:
> # FAILED
> # First few build errors in logs:
> # 00:03:49 /home/tcwg-build/workspace/tcwg_gnu_0/abe/snapshots/gcc.git~master/libgcc/libgcc2.c:2700:1: internal compiler error: Aborted
> # 00:03:49 make[2]: *** [Makefile:505: _muldc3.o] Error 1
> # 00:03:49 make[1]: *** [Makefile:14486: all-target-libgcc] Error 2
> # 00:03:49 make: *** [Makefile:1056: all] Error 2
> # 00:03:41 /home/tcwg-build/workspace/tcwg_gnu_0/abe/snapshots/gcc.git~master/libgcc/fixed-bit.c:72:1: internal compiler error: Aborted
> # 00:03:41 /home/tcwg-build/workspace/tcwg_gnu_0/abe/snapshots/gcc.git~master/libgcc/libgcc2.c:2700:1: internal compiler error: Aborted
> # 00:03:41 /home/tcwg-build/workspace/tcwg_gnu_0/abe/snapshots/gcc.git~master/libgcc/fixed-bit.c:72:1: internal compiler error: Aborted
> # 00:03:41 /home/tcwg-build/workspace/tcwg_gnu_0/abe/snapshots/gcc.git~master/libgcc/fixed-bit.c:72:1: internal compiler error: Aborted
> # 00:03:41 /home/tcwg-build/workspace/tcwg_gnu_0/abe/snapshots/gcc.git~master/libgcc/fixed-bit.c:72:1: internal compiler error: Aborted
> # 00:03:42 /home/tcwg-build/workspace/tcwg_gnu_0/abe/snapshots/gcc.git~master/libgcc/libgcc2.c:2865:1: internal compiler error: Aborted
> # 00:03:42 /home/tcwg-build/workspace/tcwg_gnu_0/abe/snapshots/gcc.git~master/libgcc/fixed-bit.c:143:1: internal compiler error: Aborted
> # 00:03:42 /home/tcwg-build/workspace/tcwg_gnu_0/abe/snapshots/gcc.git~master/libgcc/fixed-bit.c:143:1: internal compiler error: Aborted
> # 00:03:42 /home/tcwg-build/workspace/tcwg_gnu_0/abe/snapshots/gcc.git~master/libgcc/fixed-bit.c:143:1: internal compiler error: Aborted
> # 00:03:42 /home/tcwg-build/workspace/tcwg_gnu_0/abe/snapshots/gcc.git~master/libgcc/fixed-bit.c:143:1: internal compiler error: Aborted
>
> From
> # reset_artifacts:
> -10
> # true:
> 0
> # build_abe gcc:
> 1
>
> The configuration of this build is:
> CI config tcwg_gcc_build/master-arm
>
> -----------------8<--------------------------8<--------------------------8<--------------------------
> The information below can be used to reproduce a debug environment:
>
> Current build : https://ci.linaro.org/job/tcwg_gcc_build--master-arm-precommit/4076/artifac…
> Reference build : https://ci.linaro.org/job/tcwg_gcc_build--master-arm-build/1364/artifact/ar…
--
Best,
Lehua (RiVAI)
lehua.ding(a)rivai.ai