Hi!
On 2025-04-17T18:15:50+0000, ci_notify--- via Gcc-regression <gcc-regression(a)gcc.gnu.org> wrote:
> Our automatic CI has detected problems related to your patch(es). Please find some details below.
>
> In bootstrap_check master-arm-check_bootstrap, after:
> | commit gcc-15-9463-gaa3e72f9430
> | Author: Thomas Schwinge <tschwinge(a)baylibre.com>
> | Date: Thu Mar 27 23:06:37 2025 +0100
> |
> | Add test cases for exception handling constructs in dead code for GCN, nvptx target and OpenMP 'target' offloading [PR118794]
> |
> | PR target/118794
> | gcc/testsuite/
> | * g++.target/gcn/exceptions-pr118794-1.C: New.
> | ... 7 lines of the commit log omitted.
>
> Produces 2 regressions:
> |
> | regressions.sum:
> | Running libgomp:libgomp.c++/c++.exp ...
> | FAIL: libgomp.c++/target-exceptions-pr118794-1.C scan-tree-dump-times optimized "gimple_call <__builtin_eh_pointer, " 1
> | FAIL: libgomp.c++/target-exceptions-pr118794-1.C scan-tree-dump-times optimized "gimple_call <__builtin_unwind_resume, " 1
Ah, sorry for that. This is due to 'targetm.arm_eabi_unwinder', as per:
gcc/config/arm/arm.cc:#define TARGET_ARM_EABI_UNWINDER true
gcc/config/c6x/c6x.cc:#define TARGET_ARM_EABI_UNWINDER true
..., which for ARM is conditional to '#if ARM_UNWIND_INFO' (defined in
'gcc/config/arm/bpabi.h', used for various GCC configurations), and for
C6x unconditional.
This gets us:
--- target-exceptions-pr118794-1.C.269t.optimized
+++ target-exceptions-pr118794-1.C.270t.optimized
[...]
__attribute__((omp declare target))
void f ()
[...]
gimple_call <__dt_comp , NULL, &c>
- gimple_call <__builtin_eh_pointer, _7, 2>
- gimple_call <__builtin_unwind_resume, NULL, _7>
+ gimple_call <__builtin_cxa_end_cleanup, NULL>
}
[...]
There doesn't appear to be an effective-target keyword for
'targetm.arm_eabi_unwinder' specifically, do we need to add one?
Or, other test cases appear to use effective-target 'arm_eabi' to
disambiguate the two variants; is that the right thing to use here, too?
(..., plus 'tic6x-*-*' in this case?) OK to push the attached
"Adjust 'libgomp.c++/target-exceptions-pr118794-1.C' for 'targetm.arm_eabi_unwinder' [PR118794]"?
(Could Arm/C6x maintainers please test this for me?)
Grüße
Thomas
> Used configuration :
> *CI config* tcwg_bootstrap_check master-arm-check_bootstrap
> *configure and test flags:* none, autodetected on armv8l-unknown-linux-gnueabihf
>
> We track this bug report under https://linaro.atlassian.net/browse/GNU-1562. Please let us know if you have a fix.
>
> If you have any questions regarding this report, please ask on linaro-toolchain(a)lists.linaro.org mailing list.
>
> -----------------8<--------------------------8<--------------------------8<--------------------------
>
> The information below contains the details of the failures, and the ways to reproduce a debug environment:
>
> You can find the failure logs in *.log.1.xz files in
> * https://ci.linaro.org/job/tcwg_bootstrap_check--master-arm-check_bootstrap-…
> The full lists of regressions and improvements as well as configure and make commands are in
> * https://ci.linaro.org/job/tcwg_bootstrap_check--master-arm-check_bootstrap-…
> The list of [ignored] baseline and flaky failures are in
> * https://ci.linaro.org/job/tcwg_bootstrap_check--master-arm-check_bootstrap-…
>
> Current build : https://ci.linaro.org/job/tcwg_bootstrap_check--master-arm-check_bootstrap-…
> Reference build : https://ci.linaro.org/job/tcwg_bootstrap_check--master-arm-check_bootstrap-…
>
> Instruction to reproduce the build : https://git-us.linaro.org/toolchain/ci/interesting-commits.git/plain/gcc/sh…
>
> Full commit : https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=aa3e72f943032e5f074b2bd2f…
Hi,
I've looked into tests.log.1.xz and there are plenty of "Operation not
permitted" errors. I don't think that this has something to do with my
patch? Can you please check on your side, if there was a change/issue on
the build system?
Bye,
Stefan
On 4/16/25 13:32, ci_notify(a)linaro.org wrote:
> Dear contributor,
>
> Our automatic CI has detected problems related to your patch(es). Please find some details below.
>
> In glibc_check master-arm, after:
> | glibc patch https://patchwork.sourceware.org/patch/110503
> | Author: Stefan Liebler <stli(a)linux.ibm.com>
> | Date: Tue Apr 15 16:52:17 2025 +0200
> |
> | [PATCH] S390: Add new s390 platform z17.
> |
> | The glibc-hwcaps subdirectories are extended by "z17". Libraries are loaded if
> | the z17 facility bits are active:
> | - Miscellaneous-instruction-extensions facility 4
> | ... 35 lines of the commit log omitted.
> | ... applied on top of baseline commit:
> | ceeffd970c5 aarch64: Add back non-temporal load/stores from oryon-1's memset
>
> Produces 90 regressions:
> |
> | regressions.sum:
> | Running glibc:debug ...
> | FAIL: debug/tst-fortify-syslog
> | Running glibc:dirent ...
> | FAIL: dirent/tst-readdir-long
> | FAIL: dirent/tst-readdir-zero-inode
> | ... and 99 more
>
> Used configuration :
> *CI config* tcwg_glibc_check master-arm
> *configure and test flags:* none, autodetected on armv8l-unknown-linux-gnueabihf
>
> If you have any questions regarding this report, please ask on linaro-toolchain(a)lists.linaro.org mailing list.
>
> -----------------8<--------------------------8<--------------------------8<--------------------------
>
> The information below contains the details of the failures, and the ways to reproduce a debug environment:
>
> You can find the failure logs in *.log.1.xz files in
> * https://ci.linaro.org/job/tcwg_glibc_check--master-arm-precommit/3528/artif…
> The full lists of regressions and improvements as well as configure and make commands are in
> * https://ci.linaro.org/job/tcwg_glibc_check--master-arm-precommit/3528/artif…
> The list of [ignored] baseline and flaky failures are in
> * https://ci.linaro.org/job/tcwg_glibc_check--master-arm-precommit/3528/artif…
>
> Current build : https://ci.linaro.org/job/tcwg_glibc_check--master-arm-precommit/3528/artif…
> Reference build : https://ci.linaro.org/job/tcwg_glibc_check--master-arm-build/2681/artifact/…
>
> Warning: we do not enable maintainer-mode nor automatically update
> generated files, which may lead to failures if the patch modifies the
> master files.
The HTML links in your mail aren’t usable in my locked-down corporate e-mail environment. If you could just send me a list of the names of the 83 failing Fujitsu tests, I’ll look at them immediately. (The initial ones that are quoted in the mail are working now with llvm-project/main, but I’d like to check the others.)
From: ci_notify(a)linaro.org <ci_notify(a)linaro.org>
Date: Monday, April 14, 2025 at 20:36
To: ohno.yasuyuki(a)fujitsu.com <ohno.yasuyuki(a)fujitsu.com>, itou.tetsuya(a)fujitsu.com <itou.tetsuya(a)fujitsu.com>, t-kawashima(a)fujitsu.com <t-kawashima(a)fujitsu.com>
Cc: maxim.kuvyrkov(a)linaro.org <maxim.kuvyrkov(a)linaro.org>, Peter Klausler <pklausler(a)nvidia.com>
Subject: [Linaro-TCWG-CI] llvmorg-21-init-8019-g0ae9bb96d5af: 86 regressions 14 fixes on aarch64
External email: Use caution opening links or attachments
Dear contributor,
Our automatic CI has detected problems related to your patch(es). Please find some details below.
In tcwg_flang_test/main-aarch64-O3-neoverse_v1-sve_vla-mpipeliner-stack_arrays, after:
| commit llvmorg-21-init-8019-g0ae9bb96d5af
| Author: Peter Klausler <pklausler(a)nvidia.com>
| Date: Wed Apr 9 12:30:33 2025 -0700
|
| [flang][OpenMP] Fix regression in !$\ continuation (#134756)
|
| A recent patch that obviated the need to use -fopenmp when using the
| compiler to preprocess in -E mode broke a case of Fortran line
| continuation when using OpenMP conditional compilation lines (!$\) when
| ... 1 lines of the commit log omitted.
Produces 86 regressions 14 fixes:
|
| regressions.sum:
| Running test-suite:Fujitsu/Fortran/1008 ...
| NOEXE: test-suite :: Fujitsu/Fortran/1008/Fujitsu-Fortran-1008_0001.test
| NOEXE: test-suite :: Fujitsu/Fortran/1008/Fujitsu-Fortran-1008_0002.test
| NOEXE: test-suite :: Fujitsu/Fortran/1008/Fujitsu-Fortran-1008_0006.test
| NOEXE: test-suite :: Fujitsu/Fortran/1008/Fujitsu-Fortran-1008_0008.test
| ... and 84 more
| # "NOEXE" means : the test program cannot be compiled
|
| fixes.sum:
| Running test-suite:Fujitsu/Fortran/0213 ...
| NOEXE: test-suite :: Fujitsu/Fortran/0213/Fujitsu-Fortran-0213_0029.test
| NOEXE: test-suite :: Fujitsu/Fortran/0213/Fujitsu-Fortran-0213_0023.test
| NOEXE: test-suite :: Fujitsu/Fortran/0213/Fujitsu-Fortran-0213_0018.test
| NOEXE: test-suite :: Fujitsu/Fortran/0213/Fujitsu-Fortran-0213_0024.test
| ... and 10 more
| # "NOEXE" means : the test program cannot be compiled
Used configuration :
* Toolchain : cmake -G Ninja ../llvm/llvm "-DLLVM_ENABLE_PROJECTS=clang;lld;flang;openmp;clang-tools-extra" -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_ASSERTIONS=True -DCMAKE_INSTALL_PREFIX=../llvm-install "-DLLVM_TARGETS_TO_BUILD=AArch64" -DCLANG_DEFAULT_LINKER=lld
* Testsuite : export LD_LIBRARY_PATH=$\WORKSPACE/llvm-install/lib/aarch64-unknown-linux-gnu$\{LD_LIBRARY_PATH:+:$\LD_LIBRARY_PATH}
cmake -GNinja -DCMAKE_C_COMPILER="$\WORKSPACE/llvm-install/bin/clang" -DCMAKE_CXX_COMPILER="$\WORKSPACE/llvm-install/bin/clang++" -DCMAKE_Fortran_COMPILER="$\WORKSPACE/llvm-install/bin/flang-new" -DCMAKE_BUILD_TYPE=Release -DCMAKE_C_FLAGS= -DCMAKE_CXX_FLAGS= -DCMAKE_Fortran_FLAGS= -DCMAKE_C_FLAGS_RELEASE="-O3 -mcpu=neoverse-v1 -msve-vector-bits=scalable -mllvm -scalable-vectorization=preferred -mllvm -treat-scalable-fixed-error-as-warning=false -mllvm -aarch64-enable-pipeliner -mllvm -pipeliner-mve-cg -DNDEBUG" -DCMAKE_CXX_FLAGS_RELEASE="-O3 -mcpu=neoverse-v1 -msve-vector-bits=scalable -mllvm -scalable-vectorization=preferred -mllvm -treat-scalable-fixed-error-as-warning=false -mllvm -aarch64-enable-pipeliner -mllvm -pipeliner-mve-cg -DNDEBUG" -DCMAKE_Fortran_FLAGS_RELEASE="-O3 -mcpu=neoverse-v1 -msve-vector-bits=scalable -mllvm -scalable-vectorization=preferred -mllvm -treat-scalable-fixed-error-as-warning=false -mllvm -aarch64-enable-pipeliner -mllvm -pipeliner-mve-cg -DNDEBUG -fstack-arrays" -DTEST_SUITE_FORTRAN=ON -DTEST_SUITE_SUBDIRS=Fujitsu "$\WORKSPACE/test/test-suite"
We track this bug report under https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flinaro.at…<https://linaro.atlassian.net/browse/LLVM-1665>. Please let us know if you have a fix.
If you have any questions regarding this report, please ask on linaro-toolchain(a)lists.linaro.org mailing list.
-----------------8<--------------------------8<--------------------------8<--------------------------
The information below contains the details of the failures, and the ways to reproduce a debug environment:
You can find the failure logs in *.log.1.xz files in
* https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fci.linaro…<https://ci.linaro.org/job/tcwg_flang_test--main-aarch64-O3-neoverse_v1-sve_…>
The full lists of regressions and improvements as well as configure and make commands are in
* https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fci.linaro…<https://ci.linaro.org/job/tcwg_flang_test--main-aarch64-O3-neoverse_v1-sve_…>
The list of [ignored] baseline and flaky failures are in
* https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fci.linaro…<https://ci.linaro.org/job/tcwg_flang_test--main-aarch64-O3-neoverse_v1-sve_…>
Fujitsu testsuite : https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…<https://github.com/fujitsu/compiler-test-suite/>
Current build : https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fci.linaro…<https://ci.linaro.org/job/tcwg_flang_test--main-aarch64-O3-neoverse_v1-sve_…>
Reference build : https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fci.linaro…<https://ci.linaro.org/job/tcwg_flang_test--main-aarch64-O3-neoverse_v1-sve_…>
Instruction to reproduce the build : https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit-us.li…<https://git-us.linaro.org/toolchain/ci/interesting-commits.git/plain/llvm/s…>
Full commit : https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…<https://github.com/llvm/llvm-project/commit/0ae9bb96d5af47a2426596dbd0c35e3…>
Dear contributor,
This FAIL is a floating-point precision error. Please ignore this mail. We'll update the test.
> Dear contributor,
>
> Our automatic CI has detected problems related to your patch(es). Please find some details below.
>
> In tcwg_flang_test/main-aarch64-Ofast-sve_vla, after:
> | commit llvmorg-21-init-7332-g3295970d846b
> | Author: Iris <0.0(a)owo.li>
> | Date: Thu Apr 3 14:34:09 2025 +0800
> |
> | [ConstantFolding] Add support for `sinh` and `cosh` intrinsics in constant folding (#132671)
> |
> | Closes #132503.
>
> Produces 1 regression:
> |
> | regressions.sum:
> | Running test-suite:Fujitsu/Fortran/0360 ...
> | FAIL: test-suite :: Fujitsu/Fortran/0360/Fujitsu-Fortran-0360_0286.test
> | # "FAIL" means : the execution of the compiled binary failed / output of the binary differs from the expected one
>
> Used configuration :
> * Toolchain : cmake -G Ninja ../llvm/llvm "-DLLVM_ENABLE_PROJECTS=clang;lld;flang;openmp;clang-tools-extra" -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_ASSERTIONS=True -DCMAKE_INSTALL_PREFIX=../llvm-install "-DLLVM_TARGETS_TO_BUILD=AArch64" -DCLANG_DEFAULT_LINKER=lld
> * Testsuite : export LD_LIBRARY_PATH=$\WORKSPACE/llvm-install/lib/aarch64-unknown-linux-gnu$\{LD_LIBRARY_PATH:+:$\LD_LIBRARY_PATH}
> cmake -GNinja -DCMAKE_C_COMPILER="$\WORKSPACE/llvm-install/bin/clang" -DCMAKE_CXX_COMPILER="$\WORKSPACE/llvm-install/bin/clang++" -DCMAKE_Fortran_COMPILER="$\WORKSPACE/llvm-install/bin/flang-new" -DCMAKE_BUILD_TYPE=Release -DCMAKE_C_FLAGS= -DCMAKE_CXX_FLAGS= -DCMAKE_Fortran_FLAGS= -DCMAKE_C_FLAGS_RELEASE="-O3 -ffast-math -march=armv8.4-a+sve -msve-vector-bits=scalable -mllvm -scalable-vectorization=preferred -mllvm -treat-scalable-fixed-error-as-warning=false -DNDEBUG" -DCMAKE_CXX_FLAGS_RELEASE="-O3 -ffast-math -march=armv8.4-a+sve -msve-vector-bits=scalable -mllvm -scalable-vectorization=preferred -mllvm -treat-scalable-fixed-error-as-warning=false -DNDEBUG" -DCMAKE_Fortran_FLAGS_RELEASE="-O3 -ffast-math -march=armv8.4-a+sve -msve-vector-bits=scalable -mllvm -scalable-vectorization=preferred -mllvm -treat-scalable-fixed-error-as-warning=false -DNDEBUG" -DTEST_SUITE_FORTRAN=ON -DTEST_SUITE_SUBDIRS=Fujitsu "$\WORKSPACE/test/test-suite"
>
> We track this bug report under https://linaro.atlassian.net/browse/LLVM-1653. Please let us know if you have a fix.
>
> If you have any questions regarding this report, please ask on linaro-toolchain(a)lists.linaro.org mailing list.
>
> -----------------8<--------------------------8<--------------------------8<--------------------------
>
> The information below contains the details of the failures, and the ways to reproduce a debug environment:
>
> You can find the failure logs in *.log.1.xz files in
> * https://ci.linaro.org/job/tcwg_flang_test--main-aarch64-Ofast-sve_vla-build…
> The full lists of regressions and improvements as well as configure and make commands are in
> * https://ci.linaro.org/job/tcwg_flang_test--main-aarch64-Ofast-sve_vla-build…
> The list of [ignored] baseline and flaky failures are in
> * https://ci.linaro.org/job/tcwg_flang_test--main-aarch64-Ofast-sve_vla-build…
>
> Fujitsu testsuite : https://github.com/fujitsu/compiler-test-suite/
>
> Current build : https://ci.linaro.org/job/tcwg_flang_test--main-aarch64-Ofast-sve_vla-build…
> Reference build : https://ci.linaro.org/job/tcwg_flang_test--main-aarch64-Ofast-sve_vla-build…
>
> Instruction to reproduce the build : https://git-us.linaro.org/toolchain/ci/interesting-commits.git/plain/llvm/s…
>
> Full commit : https://github.com/llvm/llvm-project/commit/3295970d846b0d820b863f9eeac559b…
Hi!
On Wed, 19 Mar 2025 at 19:22, Paul Richard Thomas
<paul.richard.thomas(a)gmail.com> wrote:
>
> Hi Andre,
>
> Thanks for the review - I'll act on the points that you raised.
>
> The Linaro people reported a failure in reduce_1.f90 execution, which I believe is due to incorrect casting of 'dim' and a wrong specification of its kind. I am waiting to hear back from them as to whether or not I have fixed the failure.
>
Sorry I notice this message just today, so it's a bit outdated...
I've looked at bugzilla, so I've noticed that the are proper bug
reports about this now (and I've just checked, the problem is still
present on arm).
When you say you are "waiting to hear back from them as to whether or
not I have fixed the failure", did you contact us directly? (I'm
trying to understand if we missed your message, or how we could
improve communication).
Thanks,
Christophe
> Cheers
>
> Paul
>
>
> On Wed, 19 Mar 2025 at 12:39, Andre Vehreschild <vehre(a)gmx.de> wrote:
>>
>> Hi Paul,
>>
>> I took a look at your patch and think I found some improvements needed. In
>>
>> +bool
>> +gfc_check_reduce (gfc_expr *array, gfc_expr *operation, gfc_expr *dim,
>> + gfc_expr *mask, gfc_expr *identity, gfc_expr *ordered)
>> +{
>>
>> ...
>>
>> + if (formal->sym->attr.allocatable || formal->sym->attr.allocatable
>> + || formal->sym->attr.pointer || formal->sym->attr.pointer
>> + || formal->sym->attr.optional || formal->sym->attr.optional
>> + || formal->sym->ts.type == BT_CLASS || formal->sym->ts.type == BT_CLASS)
>> + {
>> + gfc_error ("Each argument of OPERATION at %L shall be a scalar, "
>> + "non-allocatable, non-pointer, non-polymorphic and "
>> + "nonoptional", &operation->where);
>> + return false;
>> + }
>>
>> The if is only looking at the first formal argument. The right-hand sides
>> of the || miss a ->next-> to look at the second formal argument, right?
>>
>> May be you also want to extend the tests!?
>>
>> Without having looked at it, but can't you extract the whole block of
>>
>> + if (array->ts.type == BT_CHARACTER)
>> + {
>> + unsigned long actual_size, formal_size1, formal_size2, result_size;
>> ...
>> + return false;
>> + }
>> + }
>>
>> and share it with the checks for co_reduce? I figure way to many DRY principle
>> violations are in gfortran. So when we can start this, why not do it? And a
>> call to a routine, like check_char_arg_conformance() speaks way better, then
>> having to read all that code ;-)
>>
>> In gfc_resolve_reduce() identity and ordered are marked as UNUSED. Should these
>> not a least be resolved?
>>
>> Please run contrib/check_GNU_style on your patch. It reports several issues
>> (haven't look into their validity).
>>
>> In the Changelog:
>>
>> - (gfc_check_rename): Add prototype for intrinsic with 6 arguments.
>> + * gfortran.h: Add prototype for intrinsic with 6 arguments.
>>
>> s/discription/description/
>>
>> I also encountered that nit with the executable stack when working in
>> OpenCoarrays, but haven't had time (or desire) to look into it. I will put
>> myself into CC of the pr Jerry mentioned.
>>
>> Besides the mentions above, this looks good to me.
>>
>> Thanks for the patch and
>>
>> Regards,
>> Andre
>>
>>
>>
>> On Sun, 16 Mar 2025 17:26:55 +0000
>> Paul Richard Thomas <paul.richard.thomas(a)gmail.com> wrote:
>>
>> > Hi All,
>> >
>> > This version of the REDUCE intrinsic patch has evolved somewhat since the
>> > posting on 2nd March. The most important changes are to the wrapper
>> > function and the addition of two testsuite entries.
>> >
>> > The wrapper function now effects:
>> > subroutine wrapper (a, b, c)
>> > type_of_ARRAY, intent(inout) :: a, c
>> > type_of_ARRAY, intent(inout), optional :: b
>> > if (present (b)) then
>> > c = OPERATION (a,b )
>> > else
>> > c = a
>> > end if
>> > end subroutine
>> >
>> > The reason for wrapping OPERATION in a subroutine is to allow pointer
>> > arithmetic to be used throughout in the library function. The only thing
>> > that needs to be known about the type and kind of ARRAY is the element
>> > size. The second branch in the wrapper allows deep copies to be done in the
>> > library function, such that derived types with allocatable components do
>> > not leak memory. This is needed at the final step of the algorithm to copy
>> > the result from each iteration to the result and then nullify it.
>> >
>> > This is undoubtedly a bit heavy going for intrinsic types and so, one day
>> > soon I will possibly do a bit of M4ery. That said, the present version
>> > works for all types of ARRAY and I worry a bit about how much this
>> > intrinsic will be used. Thoughts?
>> >
>> > A slight niggle is the linker error that comes up if compiled without any
>> > optimization:
>> > /usr/bin/ld: warning: /tmp/cc9cx9Rw.o: requires executable stack (because
>> > the .note.GNU-stack section is executable)
>> > I think that this is unlikely to present a security issue, however, since
>> > it disappears at -O1, I went through each of the options triggered by -O1
>> > but couldn't make it go away. Does anybody know why this is?
>> >
>> > Regtests OK with FC41/x86_64 - OK for mainline?
>> >
>> > Regards
>> >
>> > Paul
>>
>>
>> --
>> Andre Vehreschild * Email: vehre ad gmx dot de
Hello!
On 03.04.2025 14:32, ci_notify(a)linaro.org wrote:
> Our automatic CI has detected problems related to your patch(es). Please find some details below.
Could you please help me understand what the detected problem(s) are?
The mail subject suggests that everything may actually be fine?
> In binutils_build master-arm, after:
> | 5 patches in binutils
> | Patchwork URL: https://patchwork.sourceware.org/patch/109718
> | cde90675110 [PATCH 5/8] s390: Represent FP without RA saved in SFrame
> | fa5be46ad1a [PATCH 4/8] s390: Represent FP/RA saved in register in SFrame
> | b029a0bbe60 [PATCH 3/8] s390: Initial support to generate .sframe from CFI directives in assembler
> | d40f1518ae8 [PATCH 2/8] s390: Explicitly list linker dump tests
> | 45da7966615 [PATCH 1/8] sframe: Ignore section padding when converting endianness
> | ... applied on top of baseline commit:
> | abf215a338f ld/testsuite/ld-pe: Escape dots in regular expressions
My series consists of 8 patches. Could it be that they appeared in
Patchworks in a bad order, e.g. due to in what order my company's mail
server delivered them to the list, and this now confuses the CI?
https://patchwork.sourceware.org/project/binutils/list/?series=45805
> Produces Success:
> | Results changed to
> | # reset_artifacts:
> | -10
> | # true:
> | 0
> | # build_abe binutils:
> | 1
> |
> | From
> | # reset_artifacts:
> | -10
> | # true:
> | 0
> | # build_abe binutils:
> | 1
The results appear to be unchanged to me.
> Used configuration :
> *CI config* tcwg_binutils_build master-arm
> *configure and test flags:* none, autodetected on armv8l-unknown-linux-gnueabihf
>
> If you have any questions regarding this report, please ask on linaro-toolchain(a)lists.linaro.org mailing list.
>
> -----------------8<--------------------------8<--------------------------8<--------------------------
>
> The information below contains the details of the failures, and the ways to reproduce a debug environment:
>
> You can find the failure logs in
> * https://ci.linaro.org/job/tcwg_binutils_build--master-arm-precommit/3765/ar…
> The full lists of regressions and improvements as well as configure and make commands are in
> * https://ci.linaro.org/job/tcwg_binutils_build--master-arm-precommit/3765/ar…
>
> Current build : https://ci.linaro.org/job/tcwg_binutils_build--master-arm-precommit/3765/ar…
> Reference build : https://ci.linaro.org/job/tcwg_binutils_build--master-arm-build/2375/artifa…
>
> Warning: we do not enable maintainer-mode nor automatically update
> generated files, which may lead to failures if the patch modifies the
> master files.
Thanks and regards,
Jens
--
Jens Remus
Linux on Z Development (D3303)
+49-7031-16-1128 Office
jremus(a)de.ibm.com
IBM
IBM Deutschland Research & Development GmbH; Vorsitzender des Aufsichtsrats: Wolfgang Wendt; Geschäftsführung: David Faller; Sitz der Gesellschaft: Böblingen; Registergericht: Amtsgericht Stuttgart, HRB 243294
IBM Data Privacy Statement: https://www.ibm.com/privacy/