https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107868
Bug ID: 107868
Summary: [10 regression] Wrong code on AArch64 at -O1 with
new/delete
Product: gcc
Version: 10.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: victor.donascimento at arm dot com
Target Milestone: ---
The libstdc++ execution test 20_util/allocator/1.cc test fails on the head of
the gcc-10 release branch when compiled at at the -O1 optimization level.
The cddce1 tree dump reports the following elimination:
Eliminating unnecessary statements:
Deleting : _4 = ~check_delete.1_3;
Deleting : operator delete (_11, 256);
Deleting : _2 = ~check_new.0_1;
Deleting : _11 = operator new (256);
leading to the spurious loss of calls to both the new and delete operators.
bisecting between basepoints/gcc-10 and basepoints/gcc-11 identified the
following commit as introducing the error:
r10-2217-g8e8e7af514344588ff3e3da25c0cb74c12dc6a0d
Author: Martin Liska <[email protected]>
Date: Fri Aug 2 08:07:15 2019 +0200
Mark DECL_SET_IS_OPERATOR_DELETE for user-provided delete operators.
and the following as fixing the bug:
r11-3611-g0b945f959f03a6185a3130f30bfd524d01d4142c
Author: Richard Biener <[email protected]>
Date: Thu Oct 1 10:44:27 2020 +0200
make use of CALL_FROM_NEW_OR_DELETE_P
Is the above patch an appropriate fix for the issue or does it mask any further
shortcommings in the compiler?
If we're happy with the fix, should it be backported to GCC 10?
Many thanks.
Here is a reduced testcase:
#include <memory>
struct gnu { };
bool check_new = false;
bool check_delete = false;
void*
operator new(std::size_t n) noexcept(false)
{
check_new = true;
return NULL;
}
void operator delete(void *v) noexcept
{
check_delete = true;
return;
}
void operator delete(void *v, std::size_t) noexcept
{
::operator delete(v);
}
void test01()
{
std::allocator<gnu> obj;
if (!check_new)
__builtin_abort();
obj.deallocate(pobj, 256);
if (!check_delete)
__builtin_abort();
}
int main()
{
test01();
return 0;
}