This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH 0/6] Another fixes of various memory leaks
- From: Martin LiÅka <mliska at suse dot cz>
- To: Bernd Schmidt <bschmidt at redhat dot com>, gcc-patches at gcc dot gnu dot org
- Date: Mon, 23 Nov 2015 16:06:21 +0100
- Subject: Re: [PATCH 0/6] Another fixes of various memory leaks
- Authentication-results: sourceware.org; auth=none
- References: <cover dot 1448286565 dot git dot mliska at suse dot cz> <56532450 dot 9000801 at redhat dot com>
On 11/23/2015 03:36 PM, Bernd Schmidt wrote:
> On 11/23/2015 02:49 PM, marxin wrote:
>> Following series has been just bootregtested on x86_64-linux-gnu
>> (all patches together).
>
> All ok except 5/6 which I'm not finding obvious. Better to have a cilk/c++ person have a look.
Hi.
Sure, let's wait for some cilk person to do a confirmation.
>
> In the future, a few more explanations would help with reviewing. Let's say for 4/6, how does the leak occur?
Well, basically the function vect_create_cond_for_alias_checks is not called for allocated loop_vec_info.
As I am not vectorizer guy, I can't describe exact scenario how it happens.
>
> Some changes appear beneficial but unnecessary (converting explicitly released vecs to auto_vecs), and:
It's definitely beneficial, if you take a look at 'expand_an_in_modify_expr', the function
contains couple of 'return error_mark_node', where we should call ::release method.
>
>> static vec<tree, va_gc> *
>> -create_array_refs (location_t loc, vec<vec<an_parts> > an_info,
>> +create_array_refs (location_t loc, const vec<vec<an_parts> > &an_info,
>> vec<an_loop_parts> an_loop_info, size_t size, size_t rank)
>
> How does this help prevent leaks? In general we don't want non-bugfixes at this stage.
You are right, this is not directly connected to memory release. I'll remove these hunks
in the next version of the patch.
Martin
>
>
> Bernd