On Wed, May 15, 2024 at 10:22 PM Patrick O'Neill <patr...@rivosinc.com> wrote: > > > On 5/14/24 22:00, Christoph Müllner wrote: > > On Fri, May 10, 2024 at 6:01 AM Patrick O'Neill <patr...@rivosinc.com> wrote: > > Hi Christoph, > > cpymemsi-1.c fails on a subset of newlib targets. > > "UNRESOLVED: gcc.target/riscv/cpymemsi-1.c -O0 compilation failed to > produce executable" > > Full list of failing targets here (New Failures section): > https://github.com/patrick-rivos/gcc-postcommit-ci/issues/906 > > Thanks for reporting! > I'm having a hard time figuring out what the issue is here, as I can't > reproduce it locally. > This test is an execution test ("dg-do run"), so I wonder if this > might be the issue? > > riscv-gnu-toolchain configure command: ../configure --prefix=$(pwd) > -with-arch=rv32imac_zba_zbb_zbc_zbs -with-abi=ilp32 > > Here's the verbose logs: > > Executing on host: > /scratch/tc-testing/tc-upstream/build/build-gcc-newlib-stage2/gcc/xgcc > -B/scratch/tc-testing/tc-upstream/build/build-gcc-newlib-stage2/gcc/ > /scratch/tc-testing/tc-upstream/gcc/gcc/testsuite/gcc.target/riscv/cpymemsi-1.c > -march=rv32imac_zba_zbb_zbc_zbs -mabi=ilp32 -mcmodel=medlow > -fdiagnostics-plain-output -O0 -march=rv32gc -save-temps -g0 -fno-lto > -DRUN_FRACTION=11 -lm -o ./cpymemsi-1.exe (timeout = 1200) > spawn -ignore SIGHUP > /scratch/tc-testing/tc-upstream/build/build-gcc-newlib-stage2/gcc/xgcc > -B/scratch/tc-testing/tc-upstream/build/build-gcc-newlib-stage2/gcc/ > /scratch/tc-testing/tc-upstream/gcc/gcc/testsuite/gcc.target/riscv/cpymemsi-1.c > -march=rv32imac_zba_zbb_zbc_zbs -mabi=ilp32 -mcmodel=medlow > -fdiagnostics-plain-output -O0 -march=rv32gc -save-temps -g0 -fno-lto > -DRUN_FRACTION=11 -lm -o ./cpymemsi-1.exe > xgcc: fatal error: Cannot find suitable multilib set for > '-march=rv32imafdc_zicsr_zifencei'/'-mabi=ilp32' > compilation terminated. > compiler exited with status 1 > FAIL: gcc.target/riscv/cpymemsi-1.c -O0 (test for excess errors) > > Looks like it's only failing on targets without the 'f' extension so maybe we > need to add a riscv_f to avoid running on non-f targets (similar to what we > have for riscv_v)?
Ok, now I understand what's going on. For "dg-do run" tests we should be more liberal with the provided `-march` string in dg-options (or be more restrictive using effective-target checks if necessary - which is not the case here). I've sent out the following patch, which should address this issue: https://gcc.gnu.org/pipermail/gcc-patches/2024-May/651841.html BR Christoph
