[PATCH] c++: Don't require accessible dtors for some forms of new [PR59238]
Jason Merrill
jason@redhat.com
Wed Dec 9 05:35:51 GMT 2020
On 12/8/20 5:57 PM, Jakub Jelinek wrote:
> On Tue, Dec 08, 2020 at 05:34:13PM -0500, Jason Merrill wrote:
>> On 12/8/20 4:23 AM, Jakub Jelinek wrote:
>>> The earlier cases in build_new_1 already use | tf_no_cleanup, these are
>>> cases where the type isn't type_build_ctor_call nor explicit_value_init_p.
>>> It is true that often one can't delete these (unless e.g. the dtor would be
>>> private or protected and deletion done in some method), but diagnosing that
>>> belongs to delete, not new.
>>>
>>> Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
>>> trunk?
>>
>> It wasn't clear to me why adding tf_no_cleanup in those places made a
>> difference; after some investigation I tried moving the tf_no_cleanup closer
>> to where we build a TARGET_EXPR and then soon put it in an INIT_EXPR.
> I'm afraid I don't know the FE enough to know.
> I see cp_build_modify_expr can be called with INIT_EXPR from
> perform_member_init, this build_new_1 case and get_temp_regvar.
> Whether it is ok for all of them not to build destructors is something I
> have no idea about, for build_new_1 case I was confident it shouldn't be
> built.
It is OK; those other places are also using it to initialize something,
so there's never a temporary.
Applied, thanks.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 59238.diff
Type: text/x-patch
Size: 2835 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc-patches/attachments/20201209/3d9e08be/attachment.bin>
More information about the Gcc-patches
mailing list