Launchpad has imported 43 comments from the remote bug at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110812.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://documentation.ubuntu.com/launchpad/user/reference/bugs/multi-project-bugs/about-multi-project-bugs/#bugs-in-external-trackers. ------------------------------------------------------------------------ On 2023-07-26T08:36:37+00:00 Andreas Schwab wrote: The highway package fails to build with LTO: [ 5%] Linking CXX shared library libhwy.so /usr/bin/cmake -E cmake_link_script CMakeFiles/hwy.dir/link.txt --verbose=1 /usr/bin/c++ -fPIC -O2 -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -flto=auto -g -DHWY_COMPILE_ALL_ATTAINABLE -O2 -g -DNDEBUG -Wl,--version-script=/home/abuild/rpmbuild/BUILD/highway-1.0.5/hwy/hwy.version -flto=auto -Wl,--as-needed -Wl,-z,now -shared -Wl,-soname,libhwy.so.1 -o libhwy.so.1.0.5 CMakeFiles/hwy.dir/hwy/aligned_allocator.cc.o CMakeFiles/hwy.dir/hwy/nanobenchmark.cc.o CMakeFiles/hwy.dir/hwy/per_target.cc.o CMakeFiles/hwy.dir/hwy/print.cc.o CMakeFiles/hwy.dir/hwy/targets.cc.o CMakeFiles/hwy.dir/hwy/timer.cc.o lto1: fatal error: target specific builtin not available compilation terminated. lto-wrapper: fatal error: /usr/bin/c++ returned 1 exit status compilation terminated. /usr/lib64/gcc/riscv64-suse-linux/13/../../../../riscv64-suse-linux/bin/ld: error: lto-wrapper failed collect2: error: ld returned 1 exit status make[2]: *** [CMakeFiles/hwy.dir/build.make:181: libhwy.so.1.0.5] Error 1 Workaround is to add -march=rv64gcv1p0, but the correct fix is to implement TARGET_OPTION_SAVE/RESTORE. Reply at: https://bugs.launchpad.net/ubuntu/+source/highway/+bug/2121375/comments/0 ------------------------------------------------------------------------ On 2023-07-26T10:00:15+00:00 Kito-0 wrote: Ooops, I thought those target hook should implement when we have implement target attribute, anyway thanks for the hint! Reply at: https://bugs.launchpad.net/ubuntu/+source/highway/+bug/2121375/comments/1 ------------------------------------------------------------------------ On 2023-09-12T10:07:53+00:00 Andreas Schwab wrote: *** Bug 111386 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/highway/+bug/2121375/comments/2 ------------------------------------------------------------------------ On 2025-01-06T19:28:47+00:00 Andreas Schwab wrote: This also breaks openblas. Reply at: https://bugs.launchpad.net/ubuntu/+source/highway/+bug/2121375/comments/3 ------------------------------------------------------------------------ On 2025-02-03T14:30:57+00:00 Andreas Schwab wrote: The availability of builtins needs to be checked at expand time, not when the builtins are initialized. Reply at: https://bugs.launchpad.net/ubuntu/+source/highway/+bug/2121375/comments/4 ------------------------------------------------------------------------ On 2025-03-26T09:28:44+00:00 Pinskia wrote: *** Bug 119475 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/highway/+bug/2121375/comments/5 ------------------------------------------------------------------------ On 2025-04-01T14:32:04+00:00 Andreas Schwab wrote: pixman is another victim. Reply at: https://bugs.launchpad.net/ubuntu/+source/highway/+bug/2121375/comments/6 ------------------------------------------------------------------------ On 2025-05-12T16:28:03+00:00 Andreas Schwab wrote: libgcrypt is the next victim. Reply at: https://bugs.launchpad.net/ubuntu/+source/highway/+bug/2121375/comments/7 ------------------------------------------------------------------------ On 2025-05-12T20:37:13+00:00 Palmer-s wrote: Looks like our TARGET_OPTION_RESTORE is just bogus? Reply at: https://bugs.launchpad.net/ubuntu/+source/highway/+bug/2121375/comments/8 ------------------------------------------------------------------------ On 2025-05-12T21:00:59+00:00 Palmer-s wrote: Which means we just need something like this? diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc index 38f3ae7cd84..5ed6c54ff1c 100644 --- a/gcc/config/riscv/riscv.cc +++ b/gcc/config/riscv/riscv.cc @@ -10868,14 +10868,75 @@ riscv_save_restore_target_globals (tree new_tree) TREE_TARGET_GLOBALS (new_tree) = save_target_globals_default_opts (); } +/* Implements TARGET_OPTION_SAVE. Restore the backend codegen decisions + using the information saved in PTR. */ + +static void +riscv_option_save (struct cl_target_option *ptr, + struct gcc_options * /* opts_set */, + struct gcc_options *opts) +{ + ptr->x_target_flags = opts->x_target_flags; + ptr->x_riscv_stack_protector_guard_reg = opts->x_riscv_stack_protector_guard_reg; + ptr->x_riscv_stack_protector_guard_offset = opts->x_riscv_stack_protector_guard_offset; + ptr->x_riscv_zi_subext = opts->x_riscv_zi_subext; + ptr->x_riscv_za_subext = opts->x_riscv_za_subext; + ptr->x_riscv_zb_subext = opts->x_riscv_zb_subext; + ptr->x_riscv_zinx_subext = opts->x_riscv_zinx_subext; + ptr->x_riscv_zk_subext = opts->x_riscv_zk_subext; + ptr->x_riscv_vector_elen_flags = opts->x_riscv_vector_elen_flags; + ptr->x_riscv_zvl_flags = opts->x_riscv_zvl_flags; + ptr->x_riscv_zvb_subext = opts->x_riscv_zvb_subext; + ptr->x_riscv_zvk_subext = opts->x_riscv_zvk_subext; + ptr->x_riscv_zicmo_subext = opts->x_riscv_zicmo_subext; + ptr->x_riscv_mop_subext = opts->x_riscv_mop_subext; + ptr->x_riscv_zf_subext = opts->x_riscv_zf_subext; + ptr->x_riscv_zfa_subext = opts->x_riscv_zfa_subext; + ptr->x_riscv_zm_subext = opts->x_riscv_zm_subext; + ptr->x_riscv_zc_subext = opts->x_riscv_zc_subext; + ptr->x_riscv_sv_subext = opts->x_riscv_sv_subext; + ptr->x_riscv_ztso_subext = opts->x_riscv_ztso_subext; + ptr->x_riscv_xcv_subext = opts->x_riscv_xcv_subext; + ptr->x_riscv_xthead_subext = opts->x_riscv_xthead_subext; + ptr->x_riscv_xventana_subext = opts->x_riscv_xventana_subext; + ptr->x_riscv_sifive_subext = opts->x_riscv_sifive_subext; + ptr->x_riscv_fmv_priority = opts->x_riscv_fmv_priority; + +} + /* Implements TARGET_OPTION_RESTORE. Restore the backend codegen decisions using the information saved in PTR. */ static void riscv_option_restore (struct gcc_options *opts, struct gcc_options * /* opts_set */, - struct cl_target_option * /* ptr */) -{ + struct cl_target_option *ptr) +{ + opts->x_target_flags = ptr->x_target_flags; + opts->x_riscv_stack_protector_guard_reg = ptr->x_riscv_stack_protector_guard_reg; + opts->x_riscv_stack_protector_guard_offset = ptr->x_riscv_stack_protector_guard_offset; + opts->x_riscv_zi_subext = ptr->x_riscv_zi_subext; + opts->x_riscv_za_subext = ptr->x_riscv_za_subext; + opts->x_riscv_zb_subext = ptr->x_riscv_zb_subext; + opts->x_riscv_zinx_subext = ptr->x_riscv_zinx_subext; + opts->x_riscv_zk_subext = ptr->x_riscv_zk_subext; + opts->x_riscv_vector_elen_flags = ptr->x_riscv_vector_elen_flags; + opts->x_riscv_zvl_flags = ptr->x_riscv_zvl_flags; + opts->x_riscv_zvb_subext = ptr->x_riscv_zvb_subext; + opts->x_riscv_zvk_subext = ptr->x_riscv_zvk_subext; + opts->x_riscv_zicmo_subext = ptr->x_riscv_zicmo_subext; + opts->x_riscv_mop_subext = ptr->x_riscv_mop_subext; + opts->x_riscv_zf_subext = ptr->x_riscv_zf_subext; + opts->x_riscv_zfa_subext = ptr->x_riscv_zfa_subext; + opts->x_riscv_zm_subext = ptr->x_riscv_zm_subext; + opts->x_riscv_zc_subext = ptr->x_riscv_zc_subext; + opts->x_riscv_sv_subext = ptr->x_riscv_sv_subext; + opts->x_riscv_ztso_subext = ptr->x_riscv_ztso_subext; + opts->x_riscv_xcv_subext = ptr->x_riscv_xcv_subext; + opts->x_riscv_xthead_subext = ptr->x_riscv_xthead_subext; + opts->x_riscv_xventana_subext = ptr->x_riscv_xventana_subext; + opts->x_riscv_sifive_subext = ptr->x_riscv_sifive_subext; + opts->x_riscv_fmv_priority = ptr->x_riscv_fmv_priority; riscv_override_options_internal (opts); } @@ -14046,6 +14107,9 @@ bool need_shadow_stack_push_pop_p () #undef TARGET_OPTION_OVERRIDE #define TARGET_OPTION_OVERRIDE riscv_option_override +#undef TARGET_OPTION_SAVE +#define TARGET_OPTION_SAVE riscv_option_save + #undef TARGET_OPTION_RESTORE #define TARGET_OPTION_RESTORE riscv_option_restore Reply at: https://bugs.launchpad.net/ubuntu/+source/highway/+bug/2121375/comments/9 ------------------------------------------------------------------------ On 2025-05-14T15:26:41+00:00 Andreas Schwab wrote: That doesn't fix anything. https://build.opensuse.org/project/monitor/home:Andreas_Schwab:riscv:gcc Reply at: https://bugs.launchpad.net/ubuntu/+source/highway/+bug/2121375/comments/10 ------------------------------------------------------------------------ On 2025-05-23T15:17:53+00:00 Rdapp wrote: Tried building highway to reproduce and hit another error in fre... Do we have a minimal example for this issue? Reply at: https://bugs.launchpad.net/ubuntu/+source/highway/+bug/2121375/comments/11 ------------------------------------------------------------------------ On 2025-05-26T13:34:45+00:00 Andreas Schwab wrote: $ echo 'int main () {}' > empty.c $ echo '#pragma riscv intrinsic "vector" void v () { __riscv_vsetvl_e8m8 (0); }' > vector.c $ gcc -flto -c empty.c $ gcc -flto -c -march=rv64gcv vector.c $ gcc empty.o vector.o lto1: fatal error: target specific builtin not available compilation terminated. lto-wrapper: fatal error: gcc returned 1 exit status compilation terminated. /usr/lib64/gcc/riscv64-suse-linux/14/../../../../riscv64-suse-linux/bin/ld: error: lto-wrapper failed collect2: error: ld returned 1 exit status Reply at: https://bugs.launchpad.net/ubuntu/+source/highway/+bug/2121375/comments/12 ------------------------------------------------------------------------ On 2025-05-26T13:44:17+00:00 Andreas Schwab wrote: $ lto-dump -list vector.o lto-dump: fatal error: target specific builtin not available compilation terminated. Reply at: https://bugs.launchpad.net/ubuntu/+source/highway/+bug/2121375/comments/13 ------------------------------------------------------------------------ On 2025-06-02T11:17:05+00:00 Rdapp wrote: I managed to have a look now but the whole builtin and LTO machinery is kind of new to me. As Andreas mentioned already the issue is that we do not register vector builtins when the current target is !TARGET_VECTOR. This we can easily change but as we also don't enable the respective vector modes various builtin builder functions don't work. On top we deactivate certain modes depending on the current minimum vector length. Without V extension we default to a "minimum vector length" of 4 bytes which disables certain smaller vector modes. Those, in turn, need to be active when compiling another TU with the standard V extension. Also there are mutually exclusive requirements so we cannot just always enable everything and then decide at expansion time. I'm afraid I'm lacking background in LTO land - how is this supposed to work in general? If we lto compile one TU/CU with vector and another one without, while the final step does not have vector, what is the expected behavior? If one function uses vector and a vector mode that is not available in a default setting what are we supposed to do? We could set slightly other defaults, i.e. "rv64gcv" implicitly for builtin init? When compiling multiple TUs with different arch options the final executable will require the union of all those I presume? Reply at: https://bugs.launchpad.net/ubuntu/+source/highway/+bug/2121375/comments/14 ------------------------------------------------------------------------ On 2025-06-02T12:42:53+00:00 Andreas Schwab wrote: I would expect that LTO use the same machinery as the target attribute. #pragma riscv intrinsic "vector" int vl; __attribute__((target("arch=+v"))) void v () { vl = __riscv_vsetvl_e8m8 (0); } Reply at: https://bugs.launchpad.net/ubuntu/+source/highway/+bug/2121375/comments/15 ------------------------------------------------------------------------ On 2025-07-11T15:26:12+00:00 Kito-0 wrote: Created attachment 61841 0001-RISC-V-Fix-candicate-PR110812.patch Candidate patch, passed rv64gc linux regression, but not clean up enough for send formal version, just share this patch to say that I work on that and finally find a way to fix that. Reply at: https://bugs.launchpad.net/ubuntu/+source/highway/+bug/2121375/comments/16 ------------------------------------------------------------------------ On 2025-07-16T19:14:18+00:00 Andreas Schwab wrote: libtool: link: gcc -shared -fPIC -DPIC .libs/libgcrypt_la-visibility.o .libs/libgcrypt_la-misc.o .libs/libgcrypt_la-global.o .libs/libgcrypt_la-sexp.o .libs/libgcrypt_la-hwfeatures.o .libs/libgcrypt_la-stdmem.o .libs/libgcrypt_la-secmem.o .libs/libgcrypt_la-missing-string.o .libs/libgcrypt_la-fips.o .libs/libgcrypt_la-context.o .libs/libgcrypt_la-const-time.o .libs/libgcrypt_la-hwf-riscv.o -Wl,--whole-archive ../cipher/.libs/libcipher.a ../random/.libs/librandom.a ../mpi/.libs/libmpi.a ../compat/.libs/libcompat.a -Wl,--no-whole-archive -ljitterentropy -lgpg-error -O2 -fstack-protector-strong -Werror=return-type -flto=auto -g -Wl,--version-script=./libgcrypt.vers -flto=auto -Wl,-soname -Wl,libgcrypt.so.20 -o .libs/libgcrypt.so.20.5.1 during RTL pass: expand In function 'chacha20_rvv_blocks', inlined from '_gcry_chacha20_riscv_v_blocks' at ../cipher/chacha20-riscv-v.c:556:10, inlined from '_gcry_chacha20_riscv_v_blocks' at ../cipher/chacha20-riscv-v.c:553:1: ../cipher/chacha20-riscv-v.c:246:19: internal compiler error: Segmentation fault 246 | size_t vl = __riscv_vsetvl_e32m1(nblks) < 4 | ^ 0x26df613 diagnostic_context::diagnostic_impl(rich_location*, diagnostic_metadata const*, diagnostic_option_id, char const*, void**, diagnostic_t) ???:0 0x26f7c95 internal_error(char const*, ...) ???:0 0x12c540a riscv_vector::function_expander::function_expander(riscv_vector::function_instance const&, tree_node*, tree_node*, rtx_def*) ???:0 0x12c8725 riscv_vector::expand_builtin(unsigned int, tree_node*, rtx_def*) ???:0 0x95eb2f expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) ???:0 0x96d15f store_expr(tree_node*, rtx_def*, int, bool, bool) ???:0 Reply at: https://bugs.launchpad.net/ubuntu/+source/highway/+bug/2121375/comments/17 ------------------------------------------------------------------------ On 2025-08-12T14:58:58+00:00 Kito-0 wrote: Just another smaller testcase to reproduce, and seem we hit a GC issue which need to fix first...: empty.c --- void foo(); int main(){ foo(); } --- vector.c --- #include <riscv_vector.h> uint8_t *x; void foo () { int vl = __riscv_vsetvl_e8m8 (100); vint8m8_t a = __riscv_vle8_v_i8m8 (x, 100); } --- Step to reproduce: --- $ riscv64-unknown-linux-gnu-gcc empty.c -flto -c -march=rv64gc $ riscv64-unknown-linux-gnu-gcc vector.c -flto -c -march=rv64gcv $ riscv64-unknown-linux-gnu-gcc empty.o vector.o -flto -o vector -march=rv64gc during RTL pass: expand vector.c: In function 'foo': vector.c:4:13: internal compiler error: Segmentation fault 4 | int vl = __riscv_vsetvl_e8m8 (100); | ^ 0x421b9f0 internal_error(char const*, ...) ../../../../riscv-gnu-toolchain-trunk-dev/gcc/gcc/diagnostic-global-context.cc:517 0x1bcf4a3 crash_signal ../../../../riscv-gnu-toolchain-trunk-dev/gcc/gcc/toplev.cc:321 0x7326b0e4251f ??? ./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0 0x234a0a2 riscv_vector::function_call_info::function_returns_void_p() ../../../../riscv-gnu-toolchain-trunk-dev/gcc/gcc/config/riscv/riscv-vector-builtins.h:448 0x2346206 riscv_vector::function_expander::function_expander(riscv_vector::function_instance const&, tree_node*, tree_node*, rtx_def*) ../../../../riscv-gnu-toolchain-trunk-dev/gcc/gcc/config/riscv/riscv-vector-builtins.cc:4547 0x2349a6a riscv_vector::expand_builtin(unsigned int, tree_node*, rtx_def*) ../../../../riscv-gnu-toolchain-trunk-dev/gcc/gcc/config/riscv/riscv-vector-builtins.cc:5415 0x22f6aa6 riscv_expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int) ---- GDB log: ---- #7 0x000000000234a0a3 in riscv_vector::function_call_info::function_returns_void_p (this=0x7fffffffc0d0) at ../../../../riscv-gnu-toolchain-trunk-dev/gcc/gcc/config/riscv/riscv-vector-builtins.h:448 448 return TREE_TYPE (TREE_TYPE (fndecl)) == void_type_node; (gdb) call debug(fndecl) <ggc_freed 0x7ffff77a9300> ---- Reply at: https://bugs.launchpad.net/ubuntu/+source/highway/+bug/2121375/comments/18 ------------------------------------------------------------------------ On 2025-08-15T16:03:49+00:00 Sjames-j wrote: *** Bug 121565 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/highway/+bug/2121375/comments/19 ------------------------------------------------------------------------ On 2025-08-25T15:58:33+00:00 Kito-0 wrote: Created attachment 62192 v2-0001-RISC-V-Always-register-vector-built-in-function-a.patch V2 patch, verified with my latest reduced case, also included a testcase within patch. Reply at: https://bugs.launchpad.net/ubuntu/+source/highway/+bug/2121375/comments/24 ------------------------------------------------------------------------ On 2025-08-29T07:05:32+00:00 Andreas Schwab wrote: libtool: link: gcc -shared -fPIC -DPIC .libs/libgcrypt_la-visibility.o .libs/libgcrypt_la-misc.o .libs/libgcrypt_la-global.o .libs/libgcrypt_la-sexp.o .libs/libgcrypt_la-hwfeatures.o .libs/libgcrypt_la-stdmem.o .libs/libgcrypt_la-secmem.o .libs/libgcrypt_la-missing-string.o .libs/libgcrypt_la-fips.o .libs/libgcrypt_la-context.o .libs/libgcrypt_la-const-time.o .libs/libgcrypt_la-hwf-riscv.o -Wl,--whole-archive ../cipher/.libs/libcipher.a ../random/.libs/librandom.a ../mpi/.libs/libmpi.a ../compat/.libs/libcompat.a -Wl,--no-whole-archive -ljitterentropy -lgpg-error -O2 -fstack-protector-strong -Werror=return-type -flto=auto -g -Wl,--version-script=./libgcrypt.vers -flto=auto -Wl,-soname -Wl,libgcrypt.so.20 -o .libs/libgcrypt.so.20.6.0 during RTL pass: expand In function 'aes_schedule_transform', inlined from 'aes_schedule_core' at ../cipher/rijndael-vp-simd128.h:870:10, inlined from '_gcry_aes_vp_riscv_do_setkey' at ../cipher/rijndael-vp-simd128.h:913:3: ../cipher/rijndael-vp-simd128.h:586:3: internal compiler error: in generate_insn, at config/riscv/riscv-vector-builtins.cc:4962 586 | pshufb128(xmm0, xmm2); | ^ 0x273b2eb diagnostics::context::diagnostic_impl(rich_location*, diagnostics::metadata const*, diagnostics::option_id, char const*, void**, diagnostics::kind) ???:0 0x2732ac7 internal_error(char const*, ...) ???:0 0x7899ef fancy_abort(char const*, int, char const*) ???:0 0x12e9a0f riscv_vector::function_expander::generate_insn(insn_code) ???:0 0x12eca6f riscv_vector::expand_builtin(unsigned int, tree_node*, rtx_def*) ???:0 0x9791b1 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) ???:0 0x98733d store_expr(tree_node*, rtx_def*, int, bool, bool) ???:0 Reply at: https://bugs.launchpad.net/ubuntu/+source/highway/+bug/2121375/comments/28 ------------------------------------------------------------------------ On 2025-08-29T09:32:14+00:00 Kito-0 wrote: Created attachment 62231 v3-0001-RISC-V-Fix-extension-subset-check-in-riscv_can_in.patch v3 patch set (part 1), verified libgcrypt. Reply at: https://bugs.launchpad.net/ubuntu/+source/highway/+bug/2121375/comments/29 ------------------------------------------------------------------------ On 2025-08-29T09:32:41+00:00 Kito-0 wrote: Created attachment 62232 v3-0002-RISC-V-Always-register-vector-built-in-functions-.patch v3 patch set (part 2), verified libgcrypt. Reply at: https://bugs.launchpad.net/ubuntu/+source/highway/+bug/2121375/comments/30 ------------------------------------------------------------------------ On 2025-09-01T09:49:57+00:00 Andreas Schwab wrote: make[2]: Entering directory '/home/abuild/rpmbuild/BUILD/highway-1.3.0-build/highway-1.3.0/build' [ 35%] Linking CXX executable tests/arithmetic_test /usr/bin/cmake -E cmake_link_script CMakeFiles/arithmetic_test.dir/link.txt --verbose=1 /home/abuild/rpmbuild/BUILD/highway-1.3.0-build/highway-1.3.0/hwy/tests/arithmetic_test.cc: In function ‘operator().constprop’: /home/abuild/rpmbuild/BUILD/highway-1.3.0-build/highway-1.3.0/hwy/tests/arithmetic_test.cc:365:21: note: non-delegitimized UNSPEC UNSPEC_VSETVL (91) found in variable location 365 | HWY_NOINLINE void operator()(T /*unused*/, D d) { | ^ /home/abuild/rpmbuild/BUILD/highway-1.3.0-build/highway-1.3.0/hwy/tests/arithmetic_test.cc:365:21: note: non-delegitimized UNSPEC UNSPEC_VSETVL (91) found in variable location [ many "non-delegitimized UNSPEC UNSPEC_VSETVL (91) found in variable location" deleted ] during GIMPLE pass: fre /home/abuild/rpmbuild/BUILD/highway-1.3.0-build/highway-1.3.0/hwy/ops/generic_ops-inl.h: In function ‘MaskedAbsOr’: /home/abuild/rpmbuild/BUILD/highway-1.3.0-build/highway-1.3.0/hwy/ops/generic_ops-inl.h:937:11: internal compiler error: gimple check: expected gimple_assign(error_mark), have gimple_call(vec_duplicate_expr) in gimple_assign_rhs_code, at gimple.h:2919 937 | HWY_API V MaskedAbsOr(V no, M m, V v) { | ^ 0x277eeef diagnostics::context::diagnostic_impl(rich_location*, diagnostics::metadata const*, diagnostics::option_id, char const*, void**, diagnostics::kind) ???:0 0x27766cb internal_error(char const*, ...) ???:0 0x7734a3 gimple_check_failed(gimple const*, char const*, int, char const*, gimple_code, tree_code) ???:0 0x101cc6f vn_nary_length_from_stmt(gimple*) ???:0 0x10223ad vn_nary_op_lookup_stmt(gimple*, vn_nary_op_s**) ???:0 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://bugs.opensuse.org/> for instructions. make[3]: *** [/tmp/ccEwd3PZ.mk:20: /tmp/ccR9SYZQ.ltrans9.ltrans.o] Error 1 lto-wrapper: fatal error: make returned 2 exit status compilation terminated. /usr/lib64/gcc/riscv64-suse-linux/16/../../../../riscv64-suse-linux/bin/ld: error: lto-wrapper failed collect2: error: ld returned 1 exit status /usr/bin/c++ -O2 -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -flto=auto -g -O2 -g -DNDEBUG -flto=auto -Wl,--as-needed -Wl,--no-undefined -Wl,-z,now -march=rv64gcv1p0 -fPIE -pie -Wl,--dependency-file=CMakeFiles/arithmetic_test.dir/link.d CMakeFiles/arithmetic_test.dir/hwy/tests/arithmetic_test.cc.o -o tests/arithmetic_test -Wl,-rpath,/home/abuild/rpmbuild/BUILD/highway-1.3.0-build/highway-1.3.0/build libhwy_test.so.1.3.0 libhwy_contrib.so.1.3.0 /usr/lib64/libgtest.so /usr/lib64/libgtest_main.so libhwy.so.1.3.0 /usr/lib64/libgtest.so make[2]: *** [CMakeFiles/arithmetic_test.dir/build.make:110: tests/arithmetic_test] Error 1 make[2]: Leaving directory '/home/abuild/rpmbuild/BUILD/highway-1.3.0-build/highway-1.3.0/build' make[1]: *** [CMakeFiles/Makefile2:1782: CMakeFiles/arithmetic_test.dir/all] Error 2 Reply at: https://bugs.launchpad.net/ubuntu/+source/highway/+bug/2121375/comments/31 ------------------------------------------------------------------------ On 2025-09-01T13:52:08+00:00 Andreas Schwab wrote: The other packages I tested (libgcrypt, openblas, pixman, sleef, volk) now build sucessfully. Reply at: https://bugs.launchpad.net/ubuntu/+source/highway/+bug/2121375/comments/32 ------------------------------------------------------------------------ On 2025-09-01T15:02:40+00:00 Kito-0 wrote: Hi Andreas: Thanks for report the test result! And I can reproduce the highway's issue on my hand, and I suspect it's FRE's bug, I can pass with drop few patterns in gimple.md: ```diff diff --git a/gcc/match.pd b/gcc/match.pd index 66e8a7874493..198db5a0e069 100644 --- a/gcc/match.pd +++ b/gcc/match.pd @@ -10705,13 +10705,13 @@ and, (simplify (vec_cond @0 (view_convert? (uncond_op@3 @1)) @2) (with { tree op_type = TREE_TYPE (@3); } - (if (vectorized_internal_fn_supported_p (as_internal_fn (cond_op), op_type) + (if (false && vectorized_internal_fn_supported_p (as_internal_fn (cond_op), op_type) && is_truth_type_for (op_type, TREE_TYPE (@0))) (cond_op @0 (view_convert @1) @2)))) (simplify (vec_cond @0 @1 (view_convert? (uncond_op@3 @2))) (with { tree op_type = TREE_TYPE (@3); } - (if (vectorized_internal_fn_supported_p (as_internal_fn (cond_op), op_type) + (if (false && vectorized_internal_fn_supported_p (as_internal_fn (cond_op), op_type) && is_truth_type_for (op_type, TREE_TYPE (@0))) (cond_op (bit_not @0) (view_convert @2) @1))))) ``` The issue seems like the FRE's code expect the stmt is gassign but the stmt became gcall (.COND_NE) during gimple simplify, so it should not a RISC-V specific bug, I will try to extract a reduce case and file a bug for that, and meanwhile, I will send out my patch to mailing list for review :) Thanks again :) Reply at: https://bugs.launchpad.net/ubuntu/+source/highway/+bug/2121375/comments/33 ------------------------------------------------------------------------ On 2025-09-04T09:06:29+00:00 Cvs-commit wrote: The master branch has been updated by Kito Cheng <[email protected]>: https://gcc.gnu.org/g:a7fe8f83bf89704e278c1db30f51d6bb26bf0e69 commit r16-3565-ga7fe8f83bf89704e278c1db30f51d6bb26bf0e69 Author: Kito Cheng <[email protected]> Date: Thu Jul 10 15:28:30 2025 +0800 RISC-V: Always register vector built-in functions during LTO [PR110812] Previously, vector built-in functions were not properly registered during the LTO pipeline, causing link failures when vector intrinsics were used in LTO builds with mixed architecture options. This patch ensures all vector built-in functions are always registered during LTO compilation. The key changes include: - Moving pragma intrinsic flag manipulation from riscv-c.cc to riscv-vector-builtins.cc for better encapsulation - Registering all vector built-in functions regardless of current ISA extensions, deferring the actual extension checking to expansion time - Adding proper support for built-in type registration during LTO This approach is safe because we already perform extension requirement checking at expansion time. The trade-off is a slight increase in bootstrap time for LTO builds due to registering more built-in functions. PR target/110812 gcc/ChangeLog: * config/riscv/riscv-c.cc (pragma_intrinsic_flags): Remove struct. (riscv_pragma_intrinsic_flags_pollute): Remove function. (riscv_pragma_intrinsic_flags_restore): Remove function. (riscv_pragma_intrinsic): Simplify to only call handle_pragma_vector. * config/riscv/riscv-vector-builtins.cc (pragma_intrinsic_flags): Move struct definition here from riscv-c.cc. (riscv_pragma_intrinsic_flags_pollute): Move and adapt from riscv-c.cc, add zvfbfmin, zvfhmin and vector_elen_bf_16 support. (riscv_pragma_intrinsic_flags_restore): Move from riscv-c.cc. (rvv_switcher::rvv_switcher): Add pollute_flags parameter to control flag manipulation. (rvv_switcher::~rvv_switcher): Restore flags conditionally. (register_builtin_types): Use rvv_switcher without polluting flags. (get_required_extensions): Remove function. (check_required_extensions): Simplify to only check type validity. (function_instance::function_returns_void_p): Move implementation from header. (function_builder::add_function): Register placeholder for LTO. (init_builtins): Simplify and handle LTO case. (reinit_builtins): Remove function. (handle_pragma_vector): Remove extension checking. * config/riscv/riscv-vector-builtins.h (function_instance::function_returns_void_p): Add declaration. (function_call_info::function_returns_void_p): Remove inline implementation. gcc/testsuite/ChangeLog: * gcc.target/riscv/lto/pr110812_0.c: New test. * gcc.target/riscv/lto/pr110812_1.c: New test. * gcc.target/riscv/lto/riscv-lto.exp: New test driver. * gcc.target/riscv/lto/riscv_vector.h: New header wrapper. Reply at: https://bugs.launchpad.net/ubuntu/+source/highway/+bug/2121375/comments/34 ------------------------------------------------------------------------ On 2025-09-09T13:10:14+00:00 Heinrich Schuchardt wrote: Hello Kito, Will these patches be backported to 15.2? Best regards Heinrich Reply at: https://bugs.launchpad.net/ubuntu/+source/highway/+bug/2121375/comments/35 ------------------------------------------------------------------------ On 2025-09-09T13:13:04+00:00 Sjames-j wrote: I was going to ask the same thing. In this case, it'd be appreciated even though it's maybe a bigger change than we'd normally like, because it happens with so many packages. Reply at: https://bugs.launchpad.net/ubuntu/+source/highway/+bug/2121375/comments/36 ------------------------------------------------------------------------ On 2025-09-09T14:38:27+00:00 Kito-0 wrote: Yes, I plan port that to GCC 15 branch, I am just wait one week as the convention to make sure the patch is stable enough :) Reply at: https://bugs.launchpad.net/ubuntu/+source/highway/+bug/2121375/comments/37 ------------------------------------------------------------------------ On 2025-09-16T03:21:15+00:00 Law-6 wrote: *** Bug 121512 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/highway/+bug/2121375/comments/38 ------------------------------------------------------------------------ On 2025-09-22T06:40:50+00:00 Heinrich Schuchardt wrote: >> Will these patches be backported to 15.2? > Yes, I plan port that to GCC 15 branch, > I am just wait one week as the convention to make sure the patch is stable > enough Hello Kito, Is that backport already available? Thanks for all your support. Best regards Heinrich Reply at: https://bugs.launchpad.net/ubuntu/+source/highway/+bug/2121375/comments/41 ------------------------------------------------------------------------ On 2025-10-01T17:02:14+00:00 Jan-wassenberg wrote: The Highway build/tests have been exposing some compiler issues on a regular basis :) I wonder if it might be helpful to include them in the GCC test suite so that these bugs are caught sooner/closer to the source, to help reduce the time to diagnose/fix them? Reply at: https://bugs.launchpad.net/ubuntu/+source/highway/+bug/2121375/comments/47 ------------------------------------------------------------------------ On 2025-10-01T17:04:23+00:00 Sjames-j wrote: (In reply to Jan Wassenberg from comment #33) > The Highway build/tests have been exposing some compiler issues on a regular > basis :) > I wonder if it might be helpful to include them in the GCC test suite so > that these bugs are caught sooner/closer to the source, to help reduce the > time to diagnose/fix them? They're included indirectly, as we reduce testcases when they get reported. We don't generally include whole testsuites from external projects as you'd have to wrestle with integrating them cleanly, running them in parallel, configuring, etc. Reply at: https://bugs.launchpad.net/ubuntu/+source/highway/+bug/2121375/comments/48 ------------------------------------------------------------------------ On 2025-10-01T17:08:29+00:00 Law-6 wrote: Not only that, hiway is too painfully slow to build that it would blow up testing times beyond all usefullness. As Sam noted, we reduce regressions from hiway and include those. We also rely on the likes of mass builds in Fedora, Canonical, Gentoo, etc as a deeper test. Reply at: https://bugs.launchpad.net/ubuntu/+source/highway/+bug/2121375/comments/49 ------------------------------------------------------------------------ On 2025-10-02T08:13:13+00:00 Cvs-commit wrote: The releases/gcc-15 branch has been updated by Kito Cheng <[email protected]>: https://gcc.gnu.org/g:0efe904de8ce64e57db4c51e721f798ec3225b02 commit r15-10386-g0efe904de8ce64e57db4c51e721f798ec3225b02 Author: Kito Cheng <[email protected]> Date: Thu Jul 10 15:28:30 2025 +0800 RISC-V: Always register vector built-in functions during LTO [PR110812] Previously, vector built-in functions were not properly registered during the LTO pipeline, causing link failures when vector intrinsics were used in LTO builds with mixed architecture options. This patch ensures all vector built-in functions are always registered during LTO compilation. The key changes include: - Moving pragma intrinsic flag manipulation from riscv-c.cc to riscv-vector-builtins.cc for better encapsulation - Registering all vector built-in functions regardless of current ISA extensions, deferring the actual extension checking to expansion time - Adding proper support for built-in type registration during LTO This approach is safe because we already perform extension requirement checking at expansion time. The trade-off is a slight increase in bootstrap time for LTO builds due to registering more built-in functions. PR target/110812 gcc/ChangeLog: * config/riscv/riscv-c.cc (pragma_intrinsic_flags): Remove struct. (riscv_pragma_intrinsic_flags_pollute): Remove function. (riscv_pragma_intrinsic_flags_restore): Remove function. (riscv_pragma_intrinsic): Simplify to only call handle_pragma_vector. * config/riscv/riscv-vector-builtins.cc (pragma_intrinsic_flags): Move struct definition here from riscv-c.cc. (riscv_pragma_intrinsic_flags_pollute): Move and adapt from riscv-c.cc, add zvfbfmin, zvfhmin and vector_elen_bf_16 support. (riscv_pragma_intrinsic_flags_restore): Move from riscv-c.cc. (rvv_switcher::rvv_switcher): Add pollute_flags parameter to control flag manipulation. (rvv_switcher::~rvv_switcher): Restore flags conditionally. (register_builtin_types): Use rvv_switcher without polluting flags. (get_required_extensions): Remove function. (check_required_extensions): Simplify to only check type validity. (function_instance::function_returns_void_p): Move implementation from header. (function_builder::add_function): Register placeholder for LTO. (init_builtins): Simplify and handle LTO case. (reinit_builtins): Remove function. (handle_pragma_vector): Remove extension checking. * config/riscv/riscv-vector-builtins.h (function_instance::function_returns_void_p): Add declaration. (function_call_info::function_returns_void_p): Remove inline implementation. gcc/testsuite/ChangeLog: * gcc.target/riscv/lto/pr110812_0.c: New test. * gcc.target/riscv/lto/pr110812_1.c: New test. * gcc.target/riscv/lto/riscv-lto.exp: New test driver. * gcc.target/riscv/lto/riscv_vector.h: New header wrapper. Reply at: https://bugs.launchpad.net/ubuntu/+source/highway/+bug/2121375/comments/50 ------------------------------------------------------------------------ On 2025-10-03T15:05:02+00:00 Law-6 wrote: Backported to gcc-15. Closing. Reply at: https://bugs.launchpad.net/ubuntu/+source/highway/+bug/2121375/comments/52 ------------------------------------------------------------------------ On 2025-10-03T17:18:45+00:00 Sjames-j wrote: Thanks a bunch all. Reply at: https://bugs.launchpad.net/ubuntu/+source/highway/+bug/2121375/comments/53 ------------------------------------------------------------------------ On 2025-10-03T17:20:02+00:00 Jan-wassenberg wrote: > as you'd have to wrestle with integrating them cleanly, running them in > parallel, configuring, etc. Fair, thanks for sharing your thoughts. > Not only that, hiway is too painfully slow to build that it would blow up > testing times beyond all usefullness. hm, I'm curious under what circumstances? Just tried a clean make -j on an M3 laptop which finished in 1min 23sec (though with Apple clang 17). Reply at: https://bugs.launchpad.net/ubuntu/+source/highway/+bug/2121375/comments/54 ------------------------------------------------------------------------ On 2025-10-03T17:23:34+00:00 Mathieu Malaterre wrote: (In reply to Jan Wassenberg from comment #39) > > as you'd have to wrestle with integrating them cleanly, running them in > > parallel, configuring, etc. > Fair, thanks for sharing your thoughts. > > > Not only that, hiway is too painfully slow to build that it would blow up > > testing times beyond all usefullness. > hm, I'm curious under what circumstances? Just tried a clean make -j on an > M3 laptop which finished in 1min 23sec (though with Apple clang 17). I had to disable parallel building on my machine otherwise this would lock the machine totally (hard freeze). For reference here is what it takes on debian buildd amd64 (O3): * https://buildd.debian.org/status/fetch.php?pkg=highway&arch=amd64&ver=1.2.1%7Egit20240610.f384204-4&stamp=1719312782&raw=0 [...] Build needed 00:55:49, 8337616k disk space [...] 2cts Reply at: https://bugs.launchpad.net/ubuntu/+source/highway/+bug/2121375/comments/55 ------------------------------------------------------------------------ On 2025-10-26T08:27:24+00:00 Jan-wassenberg wrote: Sorry to reply late, I missed this one. Golly, 55min - that plus the hard freeze sounds like there might be swapping and/or OOM going on. It is true that the compiler is fairly RAM-hungry. FWIW my Macbook has 64 GiB and the workstation considerably more. In the medium term, we are considering moving to C++17 which would simplify the code a good bit. In the short term, I suppose limiting (or if RAM is tight entirely disabling, as you mentioned) the build parallelism is a decent workaround. Reply at: https://bugs.launchpad.net/ubuntu/+source/highway/+bug/2121375/comments/62 ------------------------------------------------------------------------ On 2026-05-03T02:24:36+00:00 Pinskia wrote: *** Bug 125157 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/highway/+bug/2121375/comments/65 ** Changed in: gcc Status: Unknown => Fix Released ** Changed in: gcc Importance: Unknown => Medium -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2121375 Title: FTBFS with GCC 15.2 To manage notifications about this bug go to: https://bugs.launchpad.net/gcc/+bug/2121375/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
