| Summary: | dev-libs/sleef-3.6.1-r1 src/arch/helperrvv.h:94:15: error: unknown type name ‘vfloat64m1x4_t’ | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Andrew Cameron <apcameron> |
| Component: | Current packages | Assignee: | Tupone Alfredo <tupone> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | apcameron, mjo, riscv, tupone |
| Priority: | Normal | Keywords: | PullRequest |
| Version: | unspecified | ||
| Hardware: | riscv | ||
| OS: | Linux | ||
| See Also: | https://github.com/gentoo/gentoo/pull/40643 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
Build log
pqv log Info log Environment |
||
Created attachment 902493 [details]
pqv log
Created attachment 902494 [details]
Info log
Created attachment 902495 [details]
Environment
It looks like your CFLAGS contain, -march=rv64imafdc_zicsr_zba_zbb (no v) but the build system has added, -march=rv64gcv_zba_zbb_zbs (with a v) for you. I'm not sure if that's 100% of the problem, but it definitely isn't going to work on a system where the 'v' is disabled or nonexistent. The Fix is to add
-DSLEEF_DISABLE_RVVM1=ON
-DSLEEF_DISABLE_RVVM2=ON
To the ebuild if the Riscv CPU does not support the vector Instructions.
Test project /var/tmp/portage/dev-libs/sleef-3.6.1-r1/work/sleef-3.6.1_build
Start 1: iut
Start 2: tester3purec_scalar
Start 3: tester3purecfma_scalar
Start 4: testervecabi
1/4 Test #4: testervecabi ..................... Passed 1.26 sec
2/4 Test #3: tester3purecfma_scalar ........... Passed 5.98 sec
3/4 Test #2: tester3purec_scalar .............. Passed 7.42 sec
4/4 Test #1: iut .............................. Passed 234.39 sec
100% tests passed, 0 tests failed out of 4
Total Test time (real) = 234.40 sec
* Tests succeeded.
>>> Completed testing dev-libs/sleef-3.6.1-r1
Hm, they're enabling any CPU features that the compiler supports, whether or not the host supports it. Even on a very old amd64 machine with no AVX instructions, I get -- Performing Test COMPILER_SUPPORTS_AVX -- Performing Test COMPILER_SUPPORTS_AVX - Success -- Performing Test COMPILER_SUPPORTS_FMA4 -- Performing Test COMPILER_SUPPORTS_FMA4 - Success -- Performing Test COMPILER_SUPPORTS_AVX2 -- Performing Test COMPILER_SUPPORTS_AVX2 - Success -- Performing Test COMPILER_SUPPORTS_AVX512F -- Performing Test COMPILER_SUPPORTS_AVX512F - Success And then it starts adding -mavx512f to my CFLAGS. On the other hand, this doesn't kill the build for me. The amd64 build completes just fine despite the lack of AVX, since, after all, what they tested was that it compiles. Likewise on my riscv64 machine, the build succeeds with their -march flags despite having no vector support on the host. So I'm still not sure why your build died... I have added a bunch of use flags to filter simd on amd64/x86 I have not found the same for riscv. cpu_flags_rv USE should be added so I can use them. Unfortunately I don't have a riscv to implement and test those flags (In reply to Tupone Alfredo from comment #7) > I have added a bunch of use flags to filter simd on amd64/x86 > > I have not found the same for riscv. > > cpu_flags_rv USE should be added so I can use them. > > Unfortunately I don't have a riscv to implement and test those flags We may need this eventually, but aren't you curious why the build failed? Why does disabling rvv1 and rvv2 fix the build for the reporter? * I'm on a similar system with no RVV * sleef detects that my compiler supports RVV1 and RVV2 * It also adds the associated -march flags (which typically don't work) ... but the build and tests succeed for me. Same thing on my amd64: the build succeeds and tests pass despite the missing features being detected in the compiler. There's something else we're missing. > Why does disabling rvv1 and rvv2 fix the build for the reporter?
>
> * I'm on a similar system with no RVV
> * sleef detects that my compiler supports RVV1 and RVV2
> * It also adds the associated -march flags (which typically don't work)
>
> ... but the build and tests succeed for me.
>
> Same thing on my amd64: the build succeeds and tests pass despite the
> missing features being detected in the compiler.
I suppose (not checking the source) that on amd64 there is a runtime test for that capability that run or not the optimized code
For the riscv, probably it check for an instruction to be compiled, in order to enable RVV1, but the enabled code uses another that is not present.
Just guessing.
(In reply to Tupone Alfredo from comment #9) > I suppose (not checking the source) that on amd64 there is a runtime test > for that capability that run or not the optimized code > > For the riscv, probably it check for an instruction to be compiled, in order > to enable RVV1, but the enabled code uses another that is not present. > > Just guessing. But I can build and test everything successfully on riscv (with no vector extensions), too. I opened a discussion upstream to see what we should be doing here: https://github.com/shibatch/sleef/discussions/576 If manually disabling the instructions is required then we'll have to put CPU_FLAGS_RV64 on the TODO list, but if sleef already has some solution to this problem it'd be nice to know why it didn't work here. (In reply to Michael Orlitzky from comment #10) > (In reply to Tupone Alfredo from comment #9) > > I suppose (not checking the source) that on amd64 there is a runtime test > > for that capability that run or not the optimized code > > > > For the riscv, probably it check for an instruction to be compiled, in order > > to enable RVV1, but the enabled code uses another that is not present. > > > > Just guessing. > > But I can build and test everything successfully on riscv (with no vector > extensions), too. > > I opened a discussion upstream to see what we should be doing here: > > https://github.com/shibatch/sleef/discussions/576 > > If manually disabling the instructions is required then we'll have to put > CPU_FLAGS_RV64 on the TODO list, but if sleef already has some solution to > this problem it'd be nice to know why it didn't work here. What version of GCC are you using? On my system it is gcc version 13.3.1 20240614 (Gentoo 13.3.1_p20240614 p17) (In reply to Andrew Cameron from comment #11) > > What version of GCC are you using? > On my system it is gcc version 13.3.1 20240614 (Gentoo 13.3.1_p20240614 p17) I just upgraded but I'm pretty sure it was gcc-14.2.0. If I switch to clang it builds clean so I think the issue is using GCC 13
I Do not think GCC 13 fully supports the vector functions.
ctest -j 4 --test-load 999 -E iut(y)?purec(fma)?_scalar
Test project /var/tmp/portage/dev-libs/sleef-3.6.1-r1/work/sleef-3.6.1_build
Start 19: qiutrvvm2
Start 8: iutrvvm2nofma
Start 9: iutyrvvm2nofma
Start 10: tester3rvvm2nofma
1/20 Test #19: qiutrvvm2 ........................ Passed 0.05 sec
2/20 Test #8: iutrvvm2nofma .................... Passed 0.03 sec
Start 11: iutrvvm2
Start 12: iutyrvvm2
3/20 Test #9: iutyrvvm2nofma ................... Passed 0.05 sec
4/20 Test #10: tester3rvvm2nofma ................ Passed 0.04 sec
5/20 Test #11: iutrvvm2 ......................... Passed 0.03 sec
Start 13: tester3rvvm2
Start 18: qiutrvvm1
Start 2: iutrvvm1nofma
6/20 Test #12: iutyrvvm2 ........................ Passed 0.06 sec
7/20 Test #13: tester3rvvm2 ..................... Passed 0.03 sec
8/20 Test #18: qiutrvvm1 ........................ Passed 0.02 sec
Start 3: iutyrvvm1nofma
Start 4: tester3rvvm1nofma
Start 5: iutrvvm1
9/20 Test #2: iutrvvm1nofma .................... Passed 0.07 sec
10/20 Test #3: iutyrvvm1nofma ................... Passed 0.05 sec
11/20 Test #4: tester3rvvm1nofma ................ Passed 0.04 sec
Start 6: iutyrvvm1
Start 7: tester3rvvm1
Start 17: tester3printf
12/20 Test #5: iutrvvm1 ......................... Passed 0.06 sec
13/20 Test #6: iutyrvvm1 ........................ Passed 0.04 sec
14/20 Test #7: tester3rvvm1 ..................... Passed 0.03 sec
Start 1: iut
Start 14: tester3purec_scalar
Start 15: tester3purecfma_scalar
15/20 Test #15: tester3purecfma_scalar ........... Passed 12.04 sec
Start 20: qiutdspscalar
16/20 Test #14: tester3purec_scalar .............. Passed 14.73 sec
Start 16: testervecabi
17/20 Test #16: testervecabi ..................... Passed 2.54 sec
18/20 Test #20: qiutdspscalar .................... Passed 89.86 sec
19/20 Test #17: tester3printf .................... Passed 128.22 sec
20/20 Test #1: iut .............................. Passed 288.94 sec
100% tests passed, 0 tests failed out of 20
Total Test time (real) = 289.20 sec
* Tests succeeded.
Ahh OK. GCC-13 only supports the v0.11.x draft: https://github.com/riscv-non-isa/rvv-intrinsic-doc/blob/v0.11.x/rvv-intrinsic-rfc.md While GCC-14 supports 1.0: https://github.com/riscv-non-isa/rvv-intrinsic-doc/blob/v1.0.x/doc/rvv-intrinsic-spec.adoc The test that sleef is using looks for types (vint32m1_t and vint32m2_t) that are in the v0.11.x spec, but it is eventually using types (e.g. vfloat64m1x4_t) that are only in the 1.0 spec. From README: RISC-V interface in SLEEF is based on version 1.0 of the intrinsics, which is only supported from llvm version 17 and gcc version 14 onwards. Raised issues upstream: https://github.com/shibatch/sleef/issues/579 The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5f7b12accb6e68ff8db63ecdb22580222a0719aa commit 5f7b12accb6e68ff8db63ecdb22580222a0719aa Author: Jakov Smolić <jsmolic@gentoo.org> AuthorDate: 2025-02-18 22:22:56 +0000 Commit: Alfredo Tupone <tupone@gentoo.org> CommitDate: 2025-02-28 19:43:31 +0000 dev-libs/sleef: add 3.8 Closes: https://bugs.gentoo.org/939400 Signed-off-by: Jakov Smolić <jsmolic@gentoo.org> Closes: https://github.com/gentoo/gentoo/pull/40643 Signed-off-by: Alfredo Tupone <tupone@gentoo.org> dev-libs/sleef/Manifest | 1 + dev-libs/sleef/sleef-3.8.ebuild | 41 +++++++++++++++++++++++++++++++++++++++++ 2 files changed, 42 insertions(+) |
Created attachment 902492 [details] Build log sleef-3.5.1-r1 builds successfully but sleef-3.6.1-r1 fails with FAILED: src/libm/CMakeFiles/sleefrvvm1nofma.dir/sleefsimddp.c.o /usr/lib/ccache/bin/riscv64-unknown-linux-gnu-gcc -DDORENAME=1 -DENABLE_ALIAS=1 -DENABLE_BUILTIN_MATH=1 -DENABLE_RVVM1NOFMA=1 -DENABLE_SYS_getrandom=1 -I/var/tmp/portage/dev-libs/sleef-3.6.1-r1/work/sleef-3.6.1/src/common -I/var/tmp/portage/dev-libs/sleef-3.6.1-r1/work/sleef-3.6.1/src/arch -I/var/tmp/portage/dev-libs/sleef-3.6.1-r1/work/sleef-3.6.1_build/src/libm/include -I/var/tmp/portage/dev-libs/sleef-3.6.1-r1/work/sleef-3.6.1/src/libm -mabi=lp64d -march=rv64imafdc_zicsr_zba_zbb -mcpu=sifive-u74 -mtune=sifive-7-series -O2 -pipe -fomit-frame-pointer -Wall -Wno-unused-function -Wno-attributes -Wno-unused-result -Wno-psabi -ffp-contract=off -fno-math-errno -fno-trapping-math -std=gnu99 -fPIC -march=rv64gcv_zba_zbb_zbs -MD -MT src/libm/CMakeFiles/sleefrvvm1nofma.dir/sleefsimddp.c.o -MF src/libm/CMakeFiles/sleefrvvm1nofma.dir/sleefsimddp.c.o.d -o src/libm/CMakeFiles/sleefrvvm1nofma.dir/sleefsimddp.c.o -c /var/tmp/portage/dev-libs/sleef-3.6.1-r1/work/sleef-3.6.1/src/libm/sleefsimddp.c In file included from /var/tmp/portage/dev-libs/sleef-3.6.1-r1/work/sleef-3.6.1/src/libm/sleefsimddp.c:237: /var/tmp/portage/dev-libs/sleef-3.6.1-r1/work/sleef-3.6.1/src/arch/helperrvv.h:94:15: error: unknown type name ‘vfloat64m1x4_t’ 94 | static INLINE vfloat64m1x4_t __riscv_vcreate_v_f64m1x4(vfloat64m1_t x, vfloat64m1_t y, vfloat64m1_t z, vfloat64m1_t w) { | ^~~~~~~~~~~~~~ /var/tmp/portage/dev-libs/sleef-3.6.1-r1/work/sleef-3.6.1/src/arch/helperrvv.h: In function ‘__riscv_vcreate_v_f64m1x4’: /var/tmp/portage/dev-libs/sleef-3.6.1-r1/work/sleef-3.6.1/src/arch/helperrvv.h:95:5: error: unknown type name ‘vfloat64m1x4_t’; did you mean ‘vfloat64m4_t’? 95 | vfloat64m1x4_t unused; | ^~~~~~~~~~~~~~ | vfloat64m4_t /var/tmp/portage/dev-libs/sleef-3.6.1-r1/work/sleef-3.6.1/src/arch/helperrvv.h:96:12: warning: implicit declaration of function ‘__riscv_vset’; did you mean ‘__riscv_vlenb’? [-Wimplicit-function-declaration] 96 | return __riscv_vset(__riscv_vset(__riscv_vset(__riscv_vset(unused, 0, x), 1, y), 2, z), 3, w); | ^~~~~~~~~~~~ | __riscv_vlenb /var/tmp/portage/dev-libs/sleef-3.6.1-r1/work/sleef-3.6.1/src/arch/helperrvv.h: At top level: /var/tmp/portage/dev-libs/sleef-3.6.1-r1/work/sleef-3.6.1/src/arch/helperrvv.h:98:15: error: unknown type name ‘vfloat64m2x4_t’ 98 | static INLINE vfloat64m2x4_t __riscv_vcreate_v_f64m2x4(vfloat64m2_t x, vfloat64m2_t y, vfloat64m2_t z, vfloat64m2_t w) { | ^~~~~~~~~~~~~~ /var/tmp/portage/dev-libs/sleef-3.6.1-r1/work/sleef-3.6.1/src/arch/helperrvv.h: In function ‘__riscv_vcreate_v_f64m2x4’: /var/tmp/portage/dev-libs/sleef-3.6.1-r1/work/sleef-3.6.1/src/arch/helperrvv.h:99:5: error: unknown type name ‘vfloat64m2x4_t’; did you mean ‘vfloat64m4_t’? 99 | vfloat64m2x4_t unused; | ^~~~~~~~~~~~~~ | vfloat64m4_t /var/tmp/portage/dev-libs/sleef-3.6.1-r1/work/sleef-3.6.1/src/arch/helperrvv.h: At top level: /var/tmp/portage/dev-libs/sleef-3.6.1-r1/work/sleef-3.6.1/src/arch/helperrvv.h:156:9: error: unknown type name ‘vfloat64m1x4_t’ 156 | typedef vfloat64m1x4_t tdx; | ^~~~~~~~~~~~~~ /var/tmp/portage/dev-libs/sleef-3.6.1-r1/work/sleef-3.6.1/src/arch/helperrvv.h:157:9: error: unknown type name ‘vfloat64m1x4_t’ 157 | typedef vfloat64m1x4_t tdi_t; | ^~~~~~~~~~~~~~ /var/tmp/portage/dev-libs/sleef-3.6.1-r1/work/sleef-3.6.1/src/arch/helperrvv.h: In function ‘figetd_vf_di’: /var/tmp/portage/dev-libs/sleef-3.6.1-r1/work/sleef-3.6.1/src/arch/helperrvv.h:180:38: warning: implicit declaration of function ‘__riscv_vreinterpret_f32m1’; did you mean ‘__riscv_vreinterpret_v_u8m1_u32m1’? [-Wimplicit-function-declaration] 180 | #define SLEEF_RVV_SP_VREINTERPRET_VF __riscv_vreinterpret_f32m1 | ^~~~~~~~~~~~~~~~~~~~~~~~~~ /var/tmp/portage/dev-libs/sleef-3.6.1-r1/work/sleef-3.6.1/src/arch/helperrvv.h:376:10: note: in expansion of macro ‘SLEEF_RVV_SP_VREINTERPRET_VF’ 376 | return SLEEF_RVV_SP_VREINTERPRET_VF(SLEEF_RVV_SP_VGET_VI2(d, 0));