These are all expected "failures" for arm (aarch32) really; the new testcases were known to fail for that target; it is recorded as PR 224847. I was not sure how to record this besides in the commit message. Should I xfail them for the targets that are known to fail?
Thanks, Andrew Pinski
-----Original Message----- From: ci_notify@linaro.org ci_notify@linaro.org Sent: Friday, April 26, 2024 3:15 PM To: Andrew Pinski (QUIC) quic_apinski@quicinc.com Subject: [Linaro-TCWG-CI] gcc patch #89057: FAIL: 28 regressions on arm
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 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/89057 | Author: Andrew Pinski quic_apinski@quicinc.com | Date: Fri Apr 26 10:07:40 2024 -0700 | | aarch64: Fix normal returns inside functions which use eh_returns [PR114843] | | The problem here is that on a normal return path, we still restore the | eh data return when we should not. | Instead of one return path in the case of eh_return, this changes over | to use multiple returns pathes just like a normal function. | On the normal path (non-eh return), we need to skip restoring of the eh | ... 43 lines of the commit log omitted. | ... applied on top of baseline commit: | 6b86f71165d AArch64: Cleanup memset expansion
FAIL: 28 regressions
regressions.sum: === gcc tests ===
Running gcc:gcc.c-torture/execute/execute.exp ... FAIL: gcc.c-torture/execute/eh_return-1.c -O0 execution test FAIL: gcc.c-torture/execute/eh_return-1.c -O1 execution test FAIL: gcc.c-torture/execute/eh_return-1.c -O2 execution test FAIL: gcc.c-torture/execute/eh_return-1.c -O2 -flto -fno-use-linker-plugin - flto-partition=none execution test FAIL: gcc.c-torture/execute/eh_return-1.c -O2 -flto -fuse-linker-plugin -fno- fat-lto-objects execution test FAIL: gcc.c-torture/execute/eh_return-1.c -O3 -g execution test FAIL: gcc.c-torture/execute/eh_return-1.c -Os execution test ... and 22 more entries
You can find the failure logs in *.log.1.xz files in
precommit/6993/artifact/artifacts/artifacts.precommit/00-sumfiles/ The full lists of regressions and progressions as well as configure and make commands are in
precommit/6993/artifact/artifacts/artifacts.precommit/notify/ The list of [ignored] baseline and flaky failures are in
precommit/6993/artifact/artifacts/artifacts.precommit/sumfiles/xfails.xfail
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/6993/artifact/artifacts Reference build : https://ci.linaro.org/job/tcwg_gcc_check--master-arm- build/2027/artifact/artifacts
Warning: we do not enable maintainer-mode nor automatically update generated files, which may lead to failures if the patch modifies the master files.
Hello Andrew,
"Andrew Pinski (QUIC)" quic_apinski@quicinc.com writes:
These are all expected "failures" for arm (aarch32) really; the new testcases were known to fail for that target; it is recorded as PR 224847. I was not sure how to record this besides in the commit message.
Is the PR number correct? I can't find it in GCC bugzilla, nor in Sourceware's.
Should I xfail them for the targets that are known to fail?
In the GDB testsuite, we use kfail in those cases. From gdb/testsuite/README:
KFAIL
Use KFAIL for known problem of GDB itself. You must specify the GDB bug report number, as in these sample tests:
kfail "gdb/13392" "continue to marker 2"
or
setup_kfail gdb/13392 "*-*-*" kfail "continue to marker 2"
Though from grepping in gcc/testsuite it doesn't look like the GCC testsuite does the same.
-----Original Message----- From: Thiago Jung Bauermann thiago.bauermann@linaro.org Sent: Friday, April 26, 2024 3:40 PM To: Andrew Pinski (QUIC) quic_apinski@quicinc.com Cc: linaro-toolchain@lists.linaro.org Subject: Re: [Linaro-TCWG-CI] gcc patch #89057: FAIL: 28 regressions on arm
WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
Hello Andrew,
"Andrew Pinski (QUIC)" quic_apinski@quicinc.com writes:
These are all expected "failures" for arm (aarch32) really; the new testcases were known to fail for that target; it is recorded as PR 224847. I was not sure how to record this besides in the commit message.
Is the PR number correct? I can't find it in GCC bugzilla, nor in Sourceware's.
Sorry typo in this email (off by one error done by my fingers doing a copy), it should have been 114847 (it was correct in the message originally sent to the mailing list).
Should I xfail them for the targets that are known to fail?
In the GDB testsuite, we use kfail in those cases. From gdb/testsuite/README:
KFAIL
Use KFAIL for known problem of GDB itself. You must specify the GDB bug report number, as in these sample tests:
kfail "gdb/13392" "continue to marker 2"or
setup_kfail gdb/13392 "*-*-*" kfail "continue to marker 2"Though from grepping in gcc/testsuite it doesn't look like the GCC testsuite does the same.
Yes GCC just uses xfail and does not use kfail. The bigger issue is that I know for sure that arm and powerpc are known to fail currently (there might be other targets but I could only test those via compiler explore looking and just looking at the code generation to). Basically this patch is to fix the aarch64 backend and add generic testcases as there was no generic testcases beforehand. The loonarch folks fixed that backend in December but didn't add a generic testcase (which would have shown the failures on other targets earlier too).
Anyways I am working on a v2 from Wilco's suggestion from the bug report. As I mentioned I only know arm was broken because I looked at the resulting code there but I am 100% sure there are other non-major targets where we will be getting failures on this testcase.
Thanks, Andrew
-- Thiago
linaro-toolchain@lists.linaro.org
-
Andrew Pinski (QUIC) -
Thiago Jung Bauermann