==9662== Memcheck, a memory error detector ==9662== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==9662== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info ==9662== Command: ./cc1 -quiet -fdiagnostics-plain-output -O3 -o ssa-dom-thread-2.s /home/rguenther/src/gcc3/gcc/testsuite/gcc.c-torture/compile/20000717-1.c ==9662== ==9662== ==9662== HEAP SUMMARY: ==9662== in use at exit: 1,896,460 bytes in 2,886 blocks ==9662== total heap usage: 20,985 allocs, 18,099 frees, 5,929,858 bytes allocated ==9662== ==9662== 9,888 (496 direct, 9,392 indirect) bytes in 1 blocks are definitely lost in loss record 709 of 736 ==9662== at 0x4C2E94F: operator new(unsigned long) (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==9662== by 0x18BBFA5: vect_analyze_loop_form(loop*, vec_info_shared*) (tree-vect-loop.c:1472) ==9662== by 0x18C0DC8: vect_analyze_loop(loop*, vec_info_shared*) (tree-vect-loop.c:2937) ==9662== by 0x191E593: try_vectorize_loop_1(hash_table<simduid_to_vf, false, xcallocator>*&, unsigned int*, loop*, gimple*, gimple*) (tree-vectorizer.c:1008) ==9662== by 0x191ED50: try_vectorize_loop(hash_table<simduid_to_vf, false, xcallocator>*&, unsigned int*, loop*) (tree-vectorizer.c:1161) ==9662== by 0x191EF2E: vectorize_loops() (tree-vectorizer.c:1242) ==9662== by 0x172415F: (anonymous namespace)::pass_vectorize::execute(function*) (tree-ssa-loop.c:414) ==9662== by 0x12E7FEA: execute_one_pass(opt_pass*) (passes.c:2572) ==9662== by 0x12E8321: execute_pass_list_1(opt_pass*) (passes.c:2661) ==9662== by 0x12E8352: execute_pass_list_1(opt_pass*) (passes.c:2662) ==9662== by 0x12E8352: execute_pass_list_1(opt_pass*) (passes.c:2662) ==9662== by 0x12E83AA: execute_pass_list(function*, opt_pass*) (passes.c:2672)
Mine.
The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>: https://gcc.gnu.org/g:d997565c41a8a5783bf076437208f38d8ea39ced commit r11-7165-gd997565c41a8a5783bf076437208f38d8ea39ced Author: Richard Biener <rguenther@suse.de> Date: Wed Feb 10 09:06:26 2021 +0100 tree-optimization/99024 - fix leak in loop vect analysis When we analyzed a loop as epilogue but later in peeling decide we're not going to use it then in the DTOR we clear the original loops ->aux which causes us to leak the main loop vinfo. Fixed by only clearing aux if it is associated with the vinfo we're destroying. 2021-02-10 Richard Biener <rguenther@suse.de> PR tree-optimization/99024 * tree-vect-loop.c (_loop_vec_info::~_loop_vec_info): Only clear loop->aux if it is associated with the destroyed loop_vinfo.
Fixed.