[PATCH 1/2] Come up with function_decl_type and use it in tree_function_decl.

[Martin Liška]

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" <mliska@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.
>