[PATCH 15/21] PR jit/63854: lra.c: Fix leak of point_freq_vec's buffer when calling lra_inheritance

[Jeff Law]

On 11/19/14 03:46, David Malcolm wrote:
> Valgrind showed a leak of 1640 bytes per iteration of one of the jit
> testcases (I think this is per-function in a compile):
>
> 8,200 bytes in 5 blocks are definitely lost in loss record 214 of 223
>     at 0x4A0645D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
>     by 0x5D75D1F: xrealloc (xmalloc.c:177)
>     by 0x4E0C94E: void va_heap::reserve<int>(vec<int, va_heap, vl_embed>*&, unsigned int, bool) (vec.h:310)
>     by 0x4E0C7A3: vec<int, va_heap, vl_ptr>::reserve(unsigned int, bool) (vec.h:1428)
>     by 0x4E0C55A: vec<int, va_heap, vl_ptr>::reserve_exact(unsigned int) (vec.h:1448)
>     by 0x4E0C2C6: vec<int, va_heap, vl_ptr>::create(unsigned int) (vec.h:1463)
>     by 0x519B316: lra_create_live_ranges(bool) (lra-lives.c:1248)
>     by 0x5179BD7: lra(_IO_FILE*) (lra.c:2297)
>     by 0x5126C4E: do_reload() (ira.c:5380)
>     by 0x5127098: (anonymous namespace)::pass_reload::execute(function*) (ira.c:5550)
>     by 0x52235BD: execute_one_pass(opt_pass*) (passes.c:2306)
>     by 0x5223834: execute_pass_list_1(opt_pass*) (passes.c:2358)
>
> which is this line:
>    point_freq_vec.create (get_max_uid () * 2);
>
> point_freq_vec's buffer is released in lra_clear_live_ranges.
>
> Am unfamiliar with LRA, but my reading of the lra code is that the
> "live_p" boolean tracks whether or not we need to call
> lra_clear_live_ranges.
>
> Debugging calls to the above line and calls to lra_clear_live_ranges
> showed a mismatch; the call to lra_create_live_ranges before
> lra_inheritance wasn't setting live_p.
>
> Setting it after that callsite fixes the leak (though perhaps the code
> could be cleaned up by having live_p be set/cleared by the
> allocation/clear functions themselves, rather than by their callers?
> Vladimir?)
>
> gcc/ChangeLog:
> 	PR jit/63854
> 	* lra.c (lra): After creating live ranges in preparation for call
> 	to lra_inheritance, set live_p to true.
OK for the trunk.

And yes, a followup where live_p's handling moves into 
lra_create_live_ranges or something similar would be good.

Jeff