aboutsummaryrefslogtreecommitdiff
path: root/gcc/gimplify.c
diff options
context:
space:
mode:
authorJason Merrill <jason@redhat.com>2021-05-28 17:05:23 -0400
committerJason Merrill <jason@redhat.com>2021-06-01 11:38:21 -0400
commitcf2b7020ee8e9745ede527b0a3b2e0ffbafd492b (patch)
tree2cba3de452cbeda1c79403c5f1d50c957dd43118 /gcc/gimplify.c
parent620cd7861e1266991c9c2a82e1e2d5f4d723ec88 (diff)
downloadgcc-cf2b7020ee8e9745ede527b0a3b2e0ffbafd492b.zip
gcc-cf2b7020ee8e9745ede527b0a3b2e0ffbafd492b.tar.gz
gcc-cf2b7020ee8e9745ede527b0a3b2e0ffbafd492b.tar.bz2
c++: no clobber for C++20 destroying delete [PR91859]
Before C++20 added destroying operator delete, by the time we called operator delete for a pointer, the object would already be gone. But that isn't true for destroying delete. Since the optimizers' assumptions about operator delete are based on either DECL_IS_REPLACEABLE_OPERATOR (which already is not set) or CALL_FROM_NEW_OR_DELETE_P, let's avoid setting the latter flag in this case. PR c++/91859 gcc/ChangeLog: * tree.h (CALL_FROM_NEW_OR_DELETE_P): Adjust comment. gcc/cp/ChangeLog: * call.c (build_op_delete_call): Don't set CALL_FROM_NEW_OR_DELETE_P for destroying delete. * init.c (build_delete): Don't clobber before destroying delete. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/destroying-delete5.C: New test.
Diffstat (limited to 'gcc/gimplify.c')
0 files changed, 0 insertions, 0 deletions