On 7/5/19 12:09 AM, Marc Glisse wrote: > On Wed, 3 Jul 2019, Richard Biener wrote: > >> On July 3, 2019 4:53:30 PM GMT+02:00, "Martin Liška" <mli...@suse.cz> 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 >>> tree_function_decl >>>>> 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 >>> is applied? >>> >>> 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).
I hope some C++ FE maintainers can help us here? > > 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). Are you talking about this location where we set OPERATOR_NEW: https://github.com/gcc-mirror/gcc/blob/master/gcc/cp/decl.c#L13643 ? That's the only place where we set OPERATOR_NEW flag and not OPERATOR_DELETE. Thanks, Martin > >> 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. >
