On 1/23/25 1:44 PM, Jakub Jelinek wrote:
Hi!The following testcase r12-6328, because the elements of the array are destructed twice, once when the callee encounters delete[] p; and then second time when the exception is thrown. The array elts should be only destructed if exception is thrown from one of the constructors during the build_vec_init emitted code in case of new expressions, but when the new expression completes, it is IMO responsibility of user code to delete[] it when it is no longer needed. So, the following patch arranges for build_vec_init emitted code to clear the rval variable used to guard the eh cleanup of it at the end, but does so only if we emit a cleanup like that and only if it is from build_new_1. For other uses of build_vec_init the elements should be IMO destructed by the compiler (and the g++.dg/{eh/{aggregate1,ref-temp2},init/aggr7-eh3}.C tests verify that behavior). Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
build_vec_init already has the cleanup_flags mechanism for suppressing cleanups. Instead of a new mechanism, how about in build_new_1 passing a flags vec and using it to disable cleanups like split_nonconstant_init does?
Or implementing the new flag using the existing mechanism rather than a new strategy of changing rval?
Jason
