diff options
author | Jason Merrill <jason@redhat.com> | 2022-01-05 09:49:37 -0500 |
---|---|---|
committer | Jason Merrill <jason@redhat.com> | 2022-01-06 19:24:31 -0500 |
commit | 2fbc45486e13facfeb05bd6ddf70ff9973a30a3c (patch) | |
tree | b3e12dc5d275caa8a5c4a443a15353387b867edd /gcc/cp/parser.c | |
parent | 40140b734487cbe03cd897dca47120317f898004 (diff) | |
download | gcc-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