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
