This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH 1/2] Come up with function_decl_type and use it in tree_function_decl.
- From: Marc Glisse <marc dot glisse at inria dot fr>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: Martin Liška <mliska at suse dot cz>, gcc-patches at gcc dot gnu dot org, David Malcolm <dmalcolm at redhat dot com>, dominik dot infuehr at theobroma-systems dot com
- Date: Fri, 5 Jul 2019 00:09:05 +0200 (CEST)
- Subject: Re: [PATCH 1/2] Come up with function_decl_type and use it in tree_function_decl.
- References: <8305B5F4-2A96-4698-8C2E-3255658B5C12@theobroma-systems.com> <CAFiYyc2nZ4vSGa5d_ni0km2kwUtyd9+BScrKzxKdbhZVfirstname.lastname@example.org> <20171122103742.GN14653@tucnak> <BC60F078-9257-4E4F-8D94-7C41F7C7B802@theobroma-systems.com> <email@example.com> <20171129083045.GX2353@tucnak> <firstname.lastname@example.org> <email@example.com> <alpine.DEB.firstname.lastname@example.org> <email@example.com> <alpine.DEB.firstname.lastname@example.org> <email@example.com> <9D090495-3C97-4873-B0DF-2610B478F621@gmail.com>
On Wed, 3 Jul 2019, Richard Biener wrote:
On July 3, 2019 4:53:30 PM GMT+02:00, "Martin Liška" <firstname.lastname@example.org> wrote:
On 7/2/19 7:15 PM, Marc Glisse wrote:
On Tue, 2 Jul 2019, Martin Liška wrote:
After the discussion with Richi and Nathan, I made a place in
and I rebased the original Dominik's patch on top of that.
So, last time there were some questions about the legality of this
transformation. Did you change the exact set of functions on which this
Yes. I was not included in the original discussion, but I hope the
transformation is valid.
Btw. clang also removes the new/delete pairs and I guess it was the
original motivation of the patch.
We also remove malloc/free pairs which the C standard does not explicitly allow (but also doesn't explicitly forbid). I don't think standards need to enumerate everything allowed and I don't know any explicit wording in the C++ standard that forbids this.
The C++ standard has explicit wording allowing to remove new-delete pairs
in some circumstances (expr.new, allocator.members), so I would assume
that other circumstances are forbidden (not that I care much, I am just
afraid someone might).
The patch apparently has DECL_IS_OPERATOR_DELETE only on the replaceable
global deallocation functions, not all delete operators, contrary to
DECL_IS_OPERATOR_NEW, so the name is misleading. On the other hand, those
seem to be the ones for which the optimization is legal (well, not quite,
the rules are in terms of operator new, and I am not sure how well
operator delete has to match, but close enough).
It's only that users can override the allocation functions (but so can
they in C) and it was suggested we need to preserve side effects unknown
to the compiler.