On Tue, Sep 22, 2026 at 09:15:55PM +0200, Jakub Jelinek wrote:
> So, we'd in that case need placement to be the vec<tree, va_gc> **placement
> argument of build_new_1 rather than the CALL_EXPR which
> build_new_1 passes in:
> 3898 /* The Standard is unclear here, but the right thing to do
> 3899 is to use the same method for finding deallocation
> 3900 functions that we use for finding allocation functions. */
> 3901 cleanup = (build_op_delete_call
> 3902 (dcode,
> 3903 alloc_node,
> 3904 size,
> 3905 globally_qualified_p,
> 3906 placement_allocation_fn_p ? alloc_call : NULL_TREE,
> 3907 alloc_fn,
> 3908 complain));
> Though, I'd be afraid we could then evaluate side-effects in the placement
> arguments multiple times.
> Or pass both placement and alloc_call and use one in fn_type_unification
> and the other in the actual call args?
Or would it be enough to just do convert_from_reference on the CALL_EXPR
args?
--- a/gcc/cp/call.cc 2026-09-22 20:44:53.000000000 +0200
+++ b/gcc/cp/call.cc 2026-09-22 21:28:11.428477377 +0200
@@ -8155,7 +8155,8 @@ build_op_delete_call_1 (enum tree_code c
args = XALLOCAVEC (tree, nargs);
args[0] = addr;
for (unsigned i = 1; i < nargs; ++i)
- args[i] = CALL_EXPR_ARG (placement, i);
+ args[i]
+ = convert_from_reference (CALL_EXPR_ARG (placement, i));
}
elt = fn_type_unification (elt, NULL_TREE, targs, args,
nargs, NULL_TREE,
on top of the incremental patch in the above mail seems to pass the
testcase.
Jakub
