Hi Jakub,
Please ignore this. I'm going to investigate, but most likely this is due to instability of guality tests.
--
Maxim Kuvyrkov
https://www.linaro.org
> On Feb 14, 2024, at 01:43, 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-1152 , please let us know if you are looking at the problem and/or when you have a fix.
>
> In gcc_check master-aarch64 after:
>
> | commit gcc-14-8948-g21de3391e4c
> | Author: Jakub Jelinek <jakub(a)redhat.com>
> | Date: Tue Feb 13 10:32:01 2024 +0100
> |
> | hwint: Fix up preprocessor conditions for GCC_PRISZ/fmt_size_t
> |
> | Using unsigned long long int for fmt_size_t and "ll" for GCC_PRISZ
> | as broke the gengtype on i686-linux before the libiberty fix is certainly
> | unexpected. size_t is there unsigned int, so expected fmt_size_t is
> | unsigned int (or some other 32-bit type).
> |
> | ... 8 lines of the commit log omitted.
>
> FAIL: 33 regressions
>
> regressions.sum:
> === gcc tests ===
>
> Running gcc:gcc.dg/guality/guality.exp ...
> FAIL: gcc.dg/guality/example.c -O1 -DPREVENT_OPTIMIZATION execution test
> FAIL: gcc.dg/guality/pr43051-1.c -O1 -DPREVENT_OPTIMIZATION line 34 c == &a[0]
> FAIL: gcc.dg/guality/pr43051-1.c -O1 -DPREVENT_OPTIMIZATION line 39 c == &a[0]
> FAIL: gcc.dg/guality/pr43051-1.c -O2 -DPREVENT_OPTIMIZATION line 34 c == &a[0]
> FAIL: gcc.dg/guality/pr43051-1.c -O2 -DPREVENT_OPTIMIZATION line 39 c == &a[0]
> FAIL: gcc.dg/guality/pr43051-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none -DPREVENT_OPTIMIZATION line 34 c == &a[0]
> FAIL: gcc.dg/guality/pr43051-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none -DPREVENT_OPTIMIZATION line 39 c == &a[0]
> ... and 27 more entries
>
> You can find the failure logs in *.log.1.xz files in
> - https://ci.linaro.org/job/tcwg_gcc_check--master-aarch64-build/1595/artifac…
> The full lists of regressions and progressions as well as configure and make commands are in
> - https://ci.linaro.org/job/tcwg_gcc_check--master-aarch64-build/1595/artifac…
> The list of [ignored] baseline and flaky failures are in
> - https://ci.linaro.org/job/tcwg_gcc_check--master-aarch64-build/1595/artifac…
>
> The configuration of this build is:
> CI config tcwg_gcc_check master-aarch64
>
> -----------------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-aarch64-build/1595/artifac…
> Reference build : https://ci.linaro.org/job/tcwg_gcc_check--master-aarch64-build/1592/artifac…
>
> 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/21de3391e4cecfef6ad1b60772cb55616c…
>
> List of configurations that regressed due to this commit :
> * tcwg_gcc_check
> ** master-aarch64
> *** FAIL: 33 regressions
> *** https://git-us.linaro.org/toolchain/ci/interesting-commits.git/plain/gcc/sh…
> *** https://ci.linaro.org/job/tcwg_gcc_check--master-aarch64-build/1595/artifac…
Hi Stephan,
Sorry this clearly looks like a false alarm.
We have enabled maintainer mode at configure time and it seems to have
unexpected consequences.
We've disabled it again, and will investigate what happened.
Sorry for the inconvenience.
Thanks,
Christophe
On Mon, 12 Feb 2024 at 14:31, <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 gdb_build master-arm after:
>
> | gdb patch https://patchwork.sourceware.org/patch/85593
> | Author: Rohr, Stephan <stephan.rohr(a)intel.com>
> | Date: Mon Feb 12 04:47:40 2024 -0800
> |
> | gdb: Fix assertion in 'value_primitive_field'
> |
> | GDB asserts that the data location of a value's field with a dynamic
> | data location is resolved when fetching the field's value in
> | 'value_primitive_field'. This assertion was hit because of bogus DWARF
> | generated by the Intel Fortran compiler. While that compiler should fix
> | the DWARF, we prefer GDB to error out here instead, e.g. to allow the
> | ... 1 lines of the commit log omitted.
> | ... applied on top of baseline commit:
> | d4a45cd4d1c Automatic date update in version.in
>
> Results changed to
> # reset_artifacts:
> -10
> # true:
> 0
> # build_abe gdb:
> # FAILED
> # First few build errors in logs:
> # 00:02:38 make: *** [Makefile:3117: all-bfd] Error 2
> # 00:01:10 make[2]: *** [Makefile:668: BLD-POTFILES.in] Error 2
> # 00:01:10 make[2]: *** [Makefile:665: SRC-POTFILES.in] Error 2
> # 00:01:10 make[1]: *** [Makefile:1952: info-recursive] Error 1
> # 00:01:10 make: *** [Makefile:3117: all-bfd] Error 2
>
> From
> # reset_artifacts:
> -10
> # true:
> 0
> # build_abe gdb:
> 1
>
> The configuration of this build is:
> CI config tcwg_gdb_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_gdb_build--master-arm-precommit/2108/artifac…
> Reference build : https://ci.linaro.org/job/tcwg_gdb_build--master-arm-build/742/artifact/art…
Hello,
In our company we are using following version of Linaro compilers. I want to know if these versions are officially supported. If these versions are NOT supported, please let me know what is the version we may need to move to take advantage of support
* LINARO-GCC - AARCH64 4.9.4
* LINARO-GCC - AARCH64 6.3.1
* LINARO-GCC 4.9 2016.2
Thanks for your help
Regards/Anand
Series:
- Cleaned QEMU device model API abuses
- Suggest new "wiring" step in QEMU device model
- Add new qemu-system binary to experiment:
- single binary
- dynamic machine
- heterogeneous emulation
Started wiki document to share work:
https://wiki.qemu.org/Dynamic_machine_and_heterogeneous_emulation_roadmap
Progress:
- Refactor ICH9 device to fix another QDev IRQ abuse
Usual reviews
- Peter's MP3R new board
Progress:
* UM-2 [QEMU upstream maintainership]
- code review and pullrequest wrangling
+ RTH's MTE fixes patchset
+ Some cleanup patches from Philippe
+ various other smaller things
- sent out some minor patches:
+ avoid some warnings being printed during 'make check'
+ fix an assertion failure trying to vmsave/vmload for M-profile
- a little gardening of the bug tracker
* QEMU-598 [Model the MPS3-AN536 dual-Cortex-R52 FPGA image]
- Finished off the loose ends and sent patchset out for review
-- PMM
Hi,
The regression was introduced after we added a new test (rev16_2.c) in https://github.com/gcc-mirror/gcc/commit/bad991a1c5960e90c4686a9362a1258ef2….
The generated code is functionally correct, but the optimization is disabled when -mthumb is equivalent to Thumb1.
The fix would not be suitable for stage 4. Instead, I opened a Jira ticket on our side to track the issue and prioritize it.
In the meantime, I am going to publish a patch to mark the test as XFAIL when used with thumb1.
Regards,
Matthieu
-----Original Message-----
From: ci_notify(a)linaro.org <ci_notify(a)linaro.org>
Sent: Thursday, February 1, 2024 5:10 PM
To: Richard Earnshaw <Richard.Earnshaw(a)arm.com>
Cc: gcc-regression(a)gcc.gnu.org; Matthieu Longo <Matthieu.Longo(a)arm.com>
Subject: [Linaro-TCWG-CI] gcc-14-8499-gbad991a1c59: FAIL: 1 regressions on master-thumb_m0_eabi
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-1141 , 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-14-8499-gbad991a1c59
| Author: Matthieu Longo <matthieu.longo(a)arm.com>
| Date: Mon Jan 29 15:54:35 2024 +0000
|
| arm: Add pattern for bswap + rotate -> rev16 [Bug 108933]
|
| The rev16 pattern was not recognised anymore as a change in the bswap
| tree pass was introducing a new GIMPLE form, not recognized by the
| assembly final transformation pass.
|
| Also, fix the output patterns for arm_rev16si_alt[12] to correctly
| ... 18 lines of the commit log omitted.
FAIL: 1 regressions
regressions.sum:
=== gcc tests ===
Running gcc:gcc.target/arm/arm.exp ...
FAIL: gcc.target/arm/rev16_2.c scan-assembler-times rev16\\tr[0-9]+, r[0-9]+ 2
You can find the failure logs in *.log.1.xz files in
- https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-thumb_m0_eabi-bu…
The full lists of regressions and progressions as well as configure and make commands are in
- https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-thumb_m0_eabi-bu…
The list of [ignored] baseline and flaky failures are in
- https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-thumb_m0_eabi-bu…
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-bu…
Reference build : https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-thumb_m0_eabi-bu…
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/bad991a1c5960e90c4686a9362a1258ef2…
List of configurations that regressed due to this commit :
* tcwg_gnu_embed_check_gcc
** master-thumb_m0_eabi
*** FAIL: 1 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-thumb_m0_eabi-bu…
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Progress:
* UM-2 [QEMU upstream maintainership]
- more code review and pullreq wrangling
* QEMU-598 [Model the MPS3-AN536 dual-Cortex-R52 FPGA image]
- Wrote code to create the CPUs and the GIC and the UARTs.
(Decided in the end not to try to create an a15mpcore-style
wrapper device for the CPUs and GIC, because the need to
have per-CPU RAM and UARTs makes that a bit awkward.)
- Got to a working implementation which can boot the selftest
binary and run those parts of the selftest which we expect
to work. Also will boot a Linux kernel (support for R52 is
not upstream but there are public mailing list patches).
- Started on tidying up the patchset and finishing off the
loose ends to get it into a state where it can be sent out:
hope to be able to do that first half of next week.
-- PMM