On Mon, 17 Feb 2025 22:49:47 -0700, Jeff Law wrote: > > > On 2/15/25 10:40 PM, Jin Ma wrote: > > On Sun, 16 Feb 2025 11:59:37 +0800, Jeff Law wrote: > >> > >> > >> On 2/14/25 12:12 AM, Jin Ma wrote: > >>> When using riscv_v_abi, the return and arguments of the function should > >>> be adequately checked to avoid ICE. > >>> > >>> PR target/118872 > >>> > >>> gcc/ChangeLog: > >>> > >>> * config/riscv/riscv.cc (riscv_fntype_abi): Strengthen the > >>> of the check to avoid missing the error report. > >>> > >>> gcc/testsuite/ChangeLog: > >>> > >>> * gcc.target/riscv/rvv/base/pr118872.c: New test. > >> Note this is causing regressions in the pre-commit CI system: > >> > >> > >>> https://github.com/ewlu/gcc-precommit-ci/issues/3096#issuecomment-2659969415 > >> > >> > >> Can you please take care of those regressions. Thanks. > > > > I sincerely apologize for the issues caused. I will work on resolving them. > > Before > > submitting, I only performed regression tests locally for rv64gc-lp64d and > > rv32gc-ilp32d, > > and it seems that was insufficient. > No worries. It happens to all of us at some point. > > For a RISC-V specific patch what I would recommend testing locally would > be a configuration of interest to you/Alibaba. It sounds like you're > already doing that, which is fantastic. > > So what I would do in the future is just wait for the pre-commit CI > system to run before actually pushing a commit to the trunk, even if the > patch has been approved. > > > You can monitor status of any given patch in the CI system you have > submitted via this URL: > > > > https://patchwork.sourceware.org/project/gcc/list/?series=&submitter=Jin+Ma&state=*&q=&archive=&delegate= > > You can further refine the search if you're so inclined.
Thank you very much for your response and guidance; it has been very helpful to me. > > > > > Additionally, I've noticed that when I run regression tests on the master > > branch using > > rv64gcv-lp64d or rv32gcv-ilp32d without applying any patches, there are > > still over 300 > > failures related to RVV. I'm unsure if there is an issue with my testing > > approach. > That sounds about right (sadly). What's more important than the number > of failures is whether or not the patch has *new* failures. ie, test > before your patch, apply the patch, test after your patch and compare > the results. There are scripts in the contrib subdirectory that will > compare the summary files. Yes, I see. Thanks again :) Best regards, Jin Ma > > Jeff
