On Mon, Jul 8, 2019 at 8:51 AM Martin Liška <mli...@suse.cz> wrote: > > 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?
Seems fine to me. [expr.new] says "An implementation is allowed to omit a call to a replaceable global allocation function (17.6.2.1, 17.6.2.2). When it does so, the storage is instead provided by the implementation or provided by extending the allocation of another new-expression." In the case of this optimization, the implementation is providing no storage, but that is fine because it is not observable. The circumstances described after the above quote have to do with when two allocations can be combined, which doesn't apply to this optimization. std::allocate says "it is unspecified when or how often [::operator new] is called." Jason