https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83414
--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
A class that uses new/delete but doesn't have a proper copy constructor defined
is a massive red flag, and that should have been obvious.
Instead of blaming GCC you could have found this using valgrind:
==27806== Memcheck, a memory error detector
==27806== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==27806== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==27806== Command: ./new
==27806==
o.v: 0x5ad3c80
p.node: 0x5ad5fc0
==27806== Invalid free() / delete / delete[] / realloc()
==27806== at 0x4C306B8: operator delete[](void*) (vg_replace_malloc.c:621)
==27806== by 0x400D88: C::~C() (new.cc:16)
==27806== by 0x400C85: main (new.cc:36)
==27806== Address 0x5ad3c80 is 0 bytes inside a block of size 72 free'd
==27806== at 0x4C306B8: operator delete[](void*) (vg_replace_malloc.c:621)
==27806== by 0x400D88: C::~C() (new.cc:16)
==27806== by 0x400C11: main (new.cc:38)
==27806== Block was alloc'd at
==27806== at 0x4C2F8B7: operator new[](unsigned long)
(vg_replace_malloc.c:423)
==27806== by 0x400D53: C::C(int) (new.cc:14)
==27806== by 0x400BEA: main (new.cc:36)
==27806==
==27806==
==27806== HEAP SUMMARY:
==27806== in use at exit: 16 bytes in 1 blocks
==27806== total heap usage: 6 allocs, 6 frees, 82,560 bytes allocated
==27806==
==27806== LEAK SUMMARY:
==27806== definitely lost: 16 bytes in 1 blocks
==27806== indirectly lost: 0 bytes in 0 blocks
==27806== possibly lost: 0 bytes in 0 blocks
==27806== still reachable: 0 bytes in 0 blocks
==27806== suppressed: 0 bytes in 0 blocks
==27806== Rerun with --leak-check=full to see details of leaked memory
==27806==
==27806== For counts of detected and suppressed errors, rerun with: -v
==27806== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Or AddressSanitizer:
o.v: 0x607000000020
p.node: 0x602000000010
=================================================================
==27834==ERROR: AddressSanitizer: attempting double-free on 0x607000000020 in
thread T0:
#0 0x7fce05749190 in operator delete[](void*) (/lib64/libasan.so.4+0xe1190)
#1 0x40171d in C::~C() /tmp/new.cc:16
#2 0x4014fe in main /tmp/new.cc:36
#3 0x7fce04a01509 in __libc_start_main (/lib64/libc.so.6+0x20509)
#4 0x400fc9 in _start (/tmp/new+0x400fc9)
0x607000000020 is located 0 bytes inside of 72-byte region
[0x607000000020,0x607000000068)
freed by thread T0 here:
#0 0x7fce05749190 in operator delete[](void*) (/lib64/libasan.so.4+0xe1190)
#1 0x40171d in C::~C() /tmp/new.cc:16
#2 0x40142a in main /tmp/new.cc:38
#3 0x7fce04a01509 in __libc_start_main (/lib64/libc.so.6+0x20509)
previously allocated by thread T0 here:
#0 0x7fce05748318 in operator new[](unsigned long)
(/lib64/libasan.so.4+0xe0318)
#1 0x40169a in C::C(int) /tmp/new.cc:14
#2 0x401357 in main /tmp/new.cc:36
#3 0x7fce04a01509 in __libc_start_main (/lib64/libc.so.6+0x20509)
SUMMARY: AddressSanitizer: double-free (/lib64/libasan.so.4+0xe1190) in
operator delete[](void*)
==27834==ABORTING
