On Tue, Nov 28, 2017 at 12:52:12PM +0100, Richard Biener wrote:
> On Mon, Nov 27, 2017 at 5:58 PM, Jeff Law <l...@redhat.com> wrote:
> > On 11/27/2017 02:22 AM, Dominik Inführ wrote:
> >> Thanks for all the reviews! I’ve revised the patch, the
> >> operator_delete_flag is now stored in tree_decl_with_vis (there already
> >> seem to be some FUNCTION_DECL-flags in there). I’ve also added the option
> >> -fallocation-dce to disable this optimization. It bootstraps and no
> >> regressions on aarch64 and x86_64.
> >>
> >> The problem with this patch is what Marc noticed: it omits too many
> >> allocations. The C++ standard seems to only allow to omit "replaceable
> >> global allocation functions (18.6.1.1, 18.6.1.2)”. So e.g. no
> >> class-specific or user-defined allocations. I am not sure what’s the best
> >> way to implement this. Just checking the function declarations might not
> >> be enough and seems more like a hack. The better way seems to introduce a
> >> __builtin_operator_new like Marc mentioned. In which way would you
> >> implement this? Could you please give me some pointers here to look at?
> > Just a nit. Make sure to mention BZ 23383 in your ChangeLog entry.
> > Like this:
> >
> > c++/23383
> > * tree-core.h (blah blah): What changed.
> >
> >
> > Jakub and Richi probably have a better understanding of the builtin
> > mechanisms than I do. I'll leave it for them to comment on how best to
> > proceed there.
>
> I don't see why a builtin is necessary, can the FE not see which one
> is the global allocation function?
It should, and finding it by namespace and name is IMHO not a hack,
that is how the C++ standard specifies those.
> Anyways, there are no FE specific builtins, traditionally FEs have
> used special keywords - you might
> want to search for RID_BUILTIN_LAUNDER for example.
Those are there just for parsing them, there is nothing special needed
to parse the standard new/delete operators.
Jakub
