public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "victor.donascimento at arm dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/107868] New: [10 regression] Wrong code on AArch64 at -O1 with new/delete Date: Fri, 25 Nov 2022 10:33:09 +0000 [thread overview] Message-ID: <bug-107868-4@http.gcc.gnu.org/bugzilla/> (raw) 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 <mliska@suse.cz> 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 <rguenther@suse.de> 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; }
next reply other threads:[~2022-11-25 10:33 UTC|newest] Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-11-25 10:33 victor.donascimento at arm dot com [this message] 2022-11-25 12:23 ` [Bug tree-optimization/107868] " marxin at gcc dot gnu.org 2022-11-25 12:26 ` rguenth at gcc dot gnu.org 2022-11-28 16:13 ` rguenth at gcc dot gnu.org 2022-11-28 16:29 ` rguenth at gcc dot gnu.org 2022-11-28 17:59 ` victor.donascimento at arm dot com 2022-11-28 18:40 ` rguenth at gcc dot gnu.org 2023-07-07 10:05 ` rguenth at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-107868-4@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).