Launchpad has imported 16 comments from the remote bug at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122270.
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 2025-10-13T12:41:16+00:00 Valentin Haudiquet wrote: When using GCC to build pytorch (https://launchpad.net/ubuntu/+source/pytorch/2.6.0+dfsg-9/+build/31323165): FAILED: caffe2/CMakeFiles/torch_cpu.dir/__/aten/src/ATen/native/cpu/DepthwiseConvKernel.cpp.DEFAULT.cpp.o /usr/bin/c++ -DAT_PER_OPERATOR_HEADERS -DCAFFE2_BUILD_MAIN_LIB -DFLASHATTENTION_DISABLE_ALIBI -DFMT_HEADER_ONLY=1 -DHAVE_MALLOC_USABLE_SIZE=1 -DHAVE_MMAP=1 -DHAVE_SHM_OPEN=1 -DHAVE_SHM_UNLINK=1 -DMINIZ_DISABLE_ZIP_READER_CRC32_CHECKS -DONNXIFI_ENABLE_EXT=1 -DONNX_ML=1 -DONNX_NAMESPACE=onnx -DTORCH_ENABLE_LLVM -DUSE_C10D_GLOO -DUSE_C10D_MPI -DUSE_DISTRIBUTED -DUSE_EXTERNAL_MZCRC -DUSE_RPC -DUSE_TENSORPIPE -D_FILE_OFFSET_BITS=64 -Dtorch_cpu_EXPORTS -I/build/reproducible-path/pytorch-2.6.0+dfsg/build/aten/src -I/build/reproducible-path/pytorch-2.6.0+dfsg/aten/src -I/build/reproducible-path/pytorch-2.6.0+dfsg/build -I/build/reproducible-path/pytorch-2.6.0+dfsg -I/build/reproducible-path/pytorch-2.6.0+dfsg/cmake/../third_party/benchmark/include -I/usr/lib/llvm-19/include -I/build/reproducible-path/pytorch-2.6.0+dfsg/nlohmann -I/build/reproducible-path/pytorch-2.6.0+dfsg/torch/csrc/api -I/build/reproducible-path/pytorch-2.6.0+dfsg/torch/csrc/api/include -I/build/reproducible-path/pytorch-2.6.0+dfsg/caffe2/aten/src/TH -I/build/reproducible-path/pytorch-2.6.0+dfsg/build/caffe2/aten/src/TH -I/build/reproducible-path/pytorch-2.6.0+dfsg/build/caffe2/aten/src -I/build/reproducible-path/pytorch-2.6.0+dfsg/build/caffe2/../aten/src -I/build/reproducible-path/pytorch-2.6.0+dfsg/torch/csrc -I/build/reproducible-path/pytorch-2.6.0+dfsg/third_party/miniz-3.0.2 -I/build/reproducible-path/pytorch-2.6.0+dfsg/debian/kineto/libkineto/include -I/build/reproducible-path/pytorch-2.6.0+dfsg/debian/kineto/libkineto/src -I/build/reproducible-path/pytorch-2.6.0+dfsg/third_party/cpp-httplib -I/build/reproducible-path/pytorch-2.6.0+dfsg/build/vulkan -I/build/reproducible-path/pytorch-2.6.0+dfsg/aten/../third_party/VulkanMemoryAllocator -I/build/reproducible-path/pytorch-2.6.0+dfsg/aten/src/ATen/.. -I/build/reproducible-path/pytorch-2.6.0+dfsg/c10/.. -I/build/reproducible-path/pytorch-2.6.0+dfsg/third_party/flatbuffers/include -isystem /build/reproducible-path/pytorch-2.6.0+dfsg/cmake/../third_party/googletest/googlemock/include -isystem /build/reproducible-path/pytorch-2.6.0+dfsg/cmake/../third_party/googletest/googletest/include -isystem /usr/include/eigen3 -isystem /build/reproducible-path/pytorch-2.6.0+dfsg/INTERFACE -isystem /build/reproducible-path/pytorch-2.6.0+dfsg/third_party/nlohmann/include -isystem /build/reproducible-path/pytorch-2.6.0+dfsg/caffe2 -isystem /usr/lib/riscv64-linux-gnu/openmpi/include -isystem /usr/lib/riscv64-linux-gnu/openmpi/include/openmpi -Wdate-time -D_FORTIFY_SOURCE=3 -g -O2 -fno-omit-frame-pointer -ffile-prefix-map=/build/reproducible-path/pytorch-2.6.0+dfsg=. -fstack-protector-strong -Wformat -Werror=format-security -fno-stack-clash-protection -fdebug-prefix-map=/build/reproducible-path/pytorch-2.6.0+dfsg=/usr/src/pytorch-2.6.0+dfsg-9 -gsplit-dwarf -Wno-dangling-reference -I/usr -D_GLIBCXX_USE_CXX11_ABI=1 -fvisibility-inlines-hidden -DUSE_KINETO -DLIBKINETO_NOCUPTI -DLIBKINETO_NOROCTRACER -DLIBKINETO_NOXPUPTI=ON -DUSE_VULKAN -DUSE_VULKAN_API -DSYMBOLICATE_MOBILE_DEBUG_HANDLE -O2 -fPIC -Wall -Wextra -Werror=return-type -Werror=non-virtual-dtor -Werror=range-loop-construct -Werror=bool-operation -Wnarrowing -Wno-missing-field-initializers -Wno-type-limits -Wno-array-bounds -Wno-unknown-pragmas -Wno-unused-parameter -Wno-strict-overflow -Wno-strict-aliasing -Wno-stringop-overflow -Wsuggest-override -Wno-psabi -Wno-error=old-style-cast -Wno-missing-braces -fdiagnostics-color=always -faligned-new -Wno-unused-but-set-variable -Wno-maybe-uninitialized -fno-math-errno -fno-trapping-math -Werror=format -Wno-error=dangling-reference -Wno-error=redundant-move -Wno-stringop-overflow -O2 -g -DNDEBUG -std=gnu++17 -fPIC -DTORCH_USE_LIBUV -DCAFFE2_USE_GLOO -Wall -Wextra -Wdeprecated -Wno-unused-parameter -Wno-missing-field-initializers -Wno-array-bounds -Wno-unknown-pragmas -Wno-strict-overflow -Wno-strict-aliasing -Wunused-function -Wunused-variable -Wunused-but-set-variable -Wno-maybe-uninitialized -fvisibility=hidden -O2 -fopenmp -O3 -DCPU_CAPABILITY=DEFAULT -DCPU_CAPABILITY_DEFAULT -MD -MT caffe2/CMakeFiles/torch_cpu.dir/__/aten/src/ATen/native/cpu/DepthwiseConvKernel.cpp.DEFAULT.cpp.o -MF caffe2/CMakeFiles/torch_cpu.dir/__/aten/src/ATen/native/cpu/DepthwiseConvKernel.cpp.DEFAULT.cpp.o.d -o caffe2/CMakeFiles/torch_cpu.dir/__/aten/src/ATen/native/cpu/DepthwiseConvKernel.cpp.DEFAULT.cpp.o -c /build/reproducible-path/pytorch-2.6.0+dfsg/build/aten/src/ATen/native/cpu/DepthwiseConvKernel.cpp.DEFAULT.cpp during GIMPLE pass: lower In file included from /build/reproducible-path/pytorch-2.6.0+dfsg/build/aten/src/ATen/native/cpu/DepthwiseConvKernel.cpp.DEFAULT.cpp:1: /build/reproducible-path/pytorch-2.6.0+dfsg/aten/src/ATen/native/cpu/DepthwiseConvKernel.cpp: In function ‘void at::native::{anonymous}::winograd_f2k3_kernel_transform__rvv(vfloat32m1_t, vfloat32m1_t, vfloat32m1_t, vfloat32m1x4_t*)’: /build/reproducible-path/pytorch-2.6.0+dfsg/aten/src/ATen/native/cpu/DepthwiseConvKernel.cpp:307:44: internal compiler error: in gsi_replace, at gimple-iterator.cc:438 307 | *transform = __riscv_vset_v_f32m1_f32m1x4(*transform, 3, g2); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~ 0x238f2c9 diagnostic_context::diagnostic_impl(rich_location*, diagnostic_metadata const*, diagnostic_option_id, char const*, void**, diagnostic_t) ???:0 0x239bfcb internal_error(char const*, ...) ???:0 0x6781cd fancy_abort(char const*, int, char const*) ???:0 0xa47005 gsi_replace(gimple_stmt_iterator*, gimple*, bool) ???:0 0x1046305 riscv_gimple_fold_builtin(gimple_stmt_iterator*) ???:0 See preprocessed source attached, or build link for full build log. Reply at: https://bugs.launchpad.net/ubuntu/+source/pytorch/+bug/2126058/comments/4 ------------------------------------------------------------------------ On 2025-10-13T12:43:23+00:00 Valentin Haudiquet wrote: Preprocessed source is above the 2MiB limit. I have uploaded it here: https://vhaudiquet.fr/files/pytorch_2.6.0+dfsg-9_riscv64_preprocessed_source.txt Reply at: https://bugs.launchpad.net/ubuntu/+source/pytorch/+bug/2126058/comments/5 ------------------------------------------------------------------------ On 2025-10-13T13:00:21+00:00 Valentin Haudiquet wrote: Created attachment 62549 gzipped preprocessed source I compressed the preprocessed source to add it as attachment here. Reply at: https://bugs.launchpad.net/ubuntu/+source/pytorch/+bug/2126058/comments/6 ------------------------------------------------------------------------ On 2025-10-13T18:14:10+00:00 Pinskia wrote: Reducing ... Reply at: https://bugs.launchpad.net/ubuntu/+source/pytorch/+bug/2126058/comments/7 ------------------------------------------------------------------------ On 2025-10-13T20:15:19+00:00 Pinskia wrote: Reduced: ``` #pragma riscv intrinsic "vector" void a(vfloat32m1_t b, vfloat32m1x4_t *c) { *c = __riscv_vset_v_f32m1_f32m1x4(*c, 3, b); } ``` Note we also get an ICE without using -march=rv64g_v with the C++ front- end (but that is a different bug). gcc_assert (!gimple_has_lhs (orig_stmt) || !gimple_has_lhs (stmt) || gimple_get_lhs (orig_stmt) == gimple_get_lhs (stmt)); Reply at: https://bugs.launchpad.net/ubuntu/+source/pytorch/+bug/2126058/comments/8 ------------------------------------------------------------------------ On 2025-10-13T20:23:21+00:00 Pinskia wrote: (In reply to Andrew Pinski from comment #4) > Reduced: > ``` > #pragma riscv intrinsic "vector" > void a(vfloat32m1_t b, vfloat32m1x4_t *c) { > *c = __riscv_vset_v_f32m1_f32m1x4(*c, 3, b); > } > ``` > > Note we also get an ICE without using -march=rv64g_v with the C++ front-end > (but that is a different bug). > > > gcc_assert (!gimple_has_lhs (orig_stmt) || !gimple_has_lhs (stmt) > || gimple_get_lhs (orig_stmt) == gimple_get_lhs (stmt)); So we are replacing the __riscv_vset_v_f32m1_f32m1x4 call stmt with: *c = *c; /* Replace the call with two statements: a copy of the full tuple to the call result, followed by an update of the individual vector. The fold routines expect the replacement statement to have the same lhs as the original call, so return the copy statement rather than the field update. */ gassign *copy = gimple_build_assign (unshare_expr (f.lhs), rhs_tuple); But unshare_expr is used here even with this comment ... This fixes the problem, switch around which get the original expression vs an unshared version: diff --git a/gcc/config/riscv/riscv-vector-builtins-bases.cc b/gcc/config/riscv/riscv-vector-builtins-bases.cc index 7e4d396f05a..ffe7c5e53d7 100644 --- a/gcc/config/riscv/riscv-vector-builtins-bases.cc +++ b/gcc/config/riscv/riscv-vector-builtins-bases.cc @@ -1793,12 +1793,12 @@ public: The fold routines expect the replacement statement to have the same lhs as the original call, so return the copy statement rather than the field update. */ - gassign *copy = gimple_build_assign (unshare_expr (f.lhs), rhs_tuple); + gassign *copy = gimple_build_assign (f.lhs, rhs_tuple); /* Get a reference to the individual vector. */ tree field = tuple_type_field (TREE_TYPE (f.lhs)); tree lhs_array - = build3 (COMPONENT_REF, TREE_TYPE (field), f.lhs, field, NULL_TREE); + = build3 (COMPONENT_REF, TREE_TYPE (field), unshare_expr (f.lhs), field, NULL_TREE); tree lhs_vector = build4 (ARRAY_REF, TREE_TYPE (rhs_vector), lhs_array, index, NULL_TREE, NULL_TREE); gassign *update = gimple_build_assign (lhs_vector, rhs_vector); Reply at: https://bugs.launchpad.net/ubuntu/+source/pytorch/+bug/2126058/comments/9 ------------------------------------------------------------------------ On 2025-10-13T20:46:38+00:00 Pinskia wrote: I should mention I have no way to test this patch. Reply at: https://bugs.launchpad.net/ubuntu/+source/pytorch/+bug/2126058/comments/10 ------------------------------------------------------------------------ On 2025-10-13T22:20:27+00:00 Law-6 wrote: If you've got something ready to test, go ahead and post, making sure RISC-V is in the subject line. The pre-commit system will see it and test it for you. Reply at: https://bugs.launchpad.net/ubuntu/+source/pytorch/+bug/2126058/comments/11 ------------------------------------------------------------------------ On 2025-10-13T22:24:02+00:00 Pinskia wrote: (In reply to Jeffrey A. Law from comment #7) > If you've got something ready to test, go ahead and post, making sure RISC-V > is in the subject line. The pre-commit system will see it and test it for > you. Let me see what I can do. I just need to add a testcase really. Reply at: https://bugs.launchpad.net/ubuntu/+source/pytorch/+bug/2126058/comments/12 ------------------------------------------------------------------------ On 2025-10-15T23:00:24+00:00 Pinskia wrote: (In reply to Andrew Pinski from comment #8) > (In reply to Jeffrey A. Law from comment #7) > > If you've got something ready to test, go ahead and post, making sure RISC-V > > is in the subject line. The pre-commit system will see it and test it for > > you. > > Let me see what I can do. I just need to add a testcase really. v2 hopefully with a fixed testcase (it is hard to test the testcase with a full toolchain): https://gcc.gnu.org/pipermail/gcc-patches/2025-October/697741.html Reply at: https://bugs.launchpad.net/ubuntu/+source/pytorch/+bug/2126058/comments/13 ------------------------------------------------------------------------ On 2025-10-24T18:37:51+00:00 Valentin Haudiquet wrote: Hello, Thank you for the patch. I'm currently trying to test it for the pytorch build. Any updates on the patch being applied, and on a potential backport to 15.2 ? It seems you mentioned that it applies cleanly, but I'm not sure what the decision is. Thanks! Reply at: https://bugs.launchpad.net/ubuntu/+source/pytorch/+bug/2126058/comments/17 ------------------------------------------------------------------------ On 2025-10-26T23:58:19+00:00 Cvs-commit wrote: The trunk branch has been updated by Andrew Pinski <[email protected]>: https://gcc.gnu.org/g:42f5f1004ff16ab25b97d3315a365614c68c6201 commit r16-4635-g42f5f1004ff16ab25b97d3315a365614c68c6201 Author: Andrew Pinski <[email protected]> Date: Wed Oct 15 09:59:25 2025 -0700 riscv: Fix gimple folding of the vset* intrinsics [PR122270] The problem here is that when the backend folds the vset intrinsics, it tries to keep the lhs of the new statement to be the same as the old statement due to the check in gsi_replace. The problem is with a MEM_REF vset::fold was unsharing the new lhs here and using the original lhs in the other new statement. This meant the check in gsi_replace would fail. This fixes that oversight by switching around which statement gets the unshared version. Note the comment in vset::fold was already correct just not matching the code: /* Replace the call with two statements: a copy of the full tuple to the call result, followed by an update of the individual vector. The fold routines expect the replacement statement to have the same lhs as the original call, so return the copy statement rather than the field update. */ Changes since v1: * v2: Fix testcase. PR target/122270 gcc/ChangeLog: * config/riscv/riscv-vector-builtins-bases.cc (vset::fold): Use the unshare_expr for the statement that will be added seperately rather the one which will be used for the replacement. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/base/pr122270-1.c: New test. Signed-off-by: Andrew Pinski <[email protected]> Reply at: https://bugs.launchpad.net/ubuntu/+source/pytorch/+bug/2126058/comments/18 ------------------------------------------------------------------------ On 2025-10-27T00:00:15+00:00 Pinskia wrote: Fixed on the trunk will backport in a week or so. Reply at: https://bugs.launchpad.net/ubuntu/+source/pytorch/+bug/2126058/comments/19 ------------------------------------------------------------------------ On 2025-11-03T20:25:12+00:00 Cvs-commit wrote: The releases/gcc-15 branch has been updated by Jeff Law <[email protected]>: https://gcc.gnu.org/g:f70ea624d1435027da9bb54d42f53caff68d97e2 commit r15-10478-gf70ea624d1435027da9bb54d42f53caff68d97e2 Author: Andrew Pinski <[email protected]> Date: Wed Oct 15 09:59:25 2025 -0700 riscv: Fix gimple folding of the vset* intrinsics [PR122270] The problem here is that when the backend folds the vset intrinsics, it tries to keep the lhs of the new statement to be the same as the old statement due to the check in gsi_replace. The problem is with a MEM_REF vset::fold was unsharing the new lhs here and using the original lhs in the other new statement. This meant the check in gsi_replace would fail. This fixes that oversight by switching around which statement gets the unshared version. Note the comment in vset::fold was already correct just not matching the code: /* Replace the call with two statements: a copy of the full tuple to the call result, followed by an update of the individual vector. The fold routines expect the replacement statement to have the same lhs as the original call, so return the copy statement rather than the field update. */ Changes since v1: * v2: Fix testcase. PR target/122270 gcc/ChangeLog: * config/riscv/riscv-vector-builtins-bases.cc (vset::fold): Use the unshare_expr for the statement that will be added seperately rather the one which will be used for the replacement. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/base/pr122270-1.c: New test. Signed-off-by: Andrew Pinski <[email protected]> (cherry picked from commit 42f5f1004ff16ab25b97d3315a365614c68c6201) Reply at: https://bugs.launchpad.net/ubuntu/+source/pytorch/+bug/2126058/comments/20 ------------------------------------------------------------------------ On 2025-11-03T20:25:57+00:00 Law-6 wrote: I went ahead and cherry-picked this over to the gcc-15 branch in preparation for tomorrow's RISC-V patchwork meeting. Reply at: https://bugs.launchpad.net/ubuntu/+source/pytorch/+bug/2126058/comments/21 ------------------------------------------------------------------------ On 2025-11-03T20:27:19+00:00 Pinskia wrote: (In reply to Jeffrey A. Law from comment #14) > I went ahead and cherry-picked this over to the gcc-15 branch in preparation > for tomorrow's RISC-V patchwork meeting. Thanks. Reply at: https://bugs.launchpad.net/ubuntu/+source/pytorch/+bug/2126058/comments/22 ** 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/2126058 Title: FTBFS: pytorch fails to build on riscv64 To manage notifications about this bug go to: https://bugs.launchpad.net/gcc/+bug/2126058/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
