aboutsummaryrefslogtreecommitdiff
path: root/gcc/cp/parser.c
diff options
context:
space:
mode:
authorJason Merrill <jason@redhat.com>2022-01-05 09:49:37 -0500
committerJason Merrill <jason@redhat.com>2022-01-06 19:24:31 -0500
commit2fbc45486e13facfeb05bd6ddf70ff9973a30a3c (patch)
treeb3e12dc5d275caa8a5c4a443a15353387b867edd /gcc/cp/parser.c
parent40140b734487cbe03cd897dca47120317f898004 (diff)
downloadgcc-2fbc45486e13facfeb05bd6ddf70ff9973a30a3c.zip
gcc-2fbc45486e13facfeb05bd6ddf70ff9973a30a3c.tar.gz
gcc-2fbc45486e13facfeb05bd6ddf70ff9973a30a3c.tar.bz2
c++: keep destroying array after one dtor throws [PR66451]
When we're cleaning up an array, if one destructor throws, we should still try to clean up the rest of the array. We can use TRY_CATCH_EXPR for this, instead of a TARGET_EXPR like my other recent patches, because a destructor call can't involve any temporaries that need to live longer. I thought about only doing this when we call build_vec_delete_1 from build_vec_init, but it seems appropriate for delete-expressions as well; we've said that the array's lifetime is over, it makes sense to keep trying to destroy it. The standard isn't clear, but clang seems to agree with me. PR c++/66451 gcc/cp/ChangeLog: * init.c (build_vec_delete_1): Handle throwing dtor. (build_vec_init): Tell it we're in a cleanup already. gcc/testsuite/ChangeLog: * g++.dg/eh/array3.C: New test. * g++.dg/eh/array1.C: Mark destructor as throw(). * g++.dg/ipa/devirt-40.C: Likewise. * g++.dg/warn/pr83054.C: Likewise. * g++.dg/eh/delete1.C: Shorten array to one element.
Diffstat (limited to 'gcc/cp/parser.c')
0 files changed, 0 insertions, 0 deletions