On Fri, Oct 17, 2025 at 6:23 PM Jeff Law <[email protected]> wrote: > > > > On 10/15/25 4:56 PM, Andrew Pinski wrote: > > 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. > FTR: The pre-commit tester and mine were both happy with this. > > OK for the trunk. One formatting nit though: > > > > > /* 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); > Overly long line reported by pre-commit lint.
Committed with added fix for long lines as r16-4635-g42f5f1004ff16ab2. Thanks, Andrew > > jeff
