On Wed, 2014-11-19 at 13:38 -0500, David Malcolm wrote: > On Wed, 2014-11-19 at 09:57 -0700, Jeff Law wrote: > > On 11/19/14 03:46, David Malcolm wrote: > > > This commit updates jit.exp so that if RUN_UNDER_VALGRIND is present > > > in the environment, all of the built client code using libgccjit.so is > > > run under valgrind, with --leak-check=full. > > > > > > Hence: > > > RUN_UNDER_VALGRIND= make check-jit > > > will run all jit testcases under valgrind (taking 27 mins on my > > > machine). > > > > > > Results are written to testsuite/jit/test-FOO.exe.valgrind.txt > > > > > > jit.exp automatically parses these result file, looking for lines of > > > the form > > > definitely lost: 11,316 bytes in 235 blocks > > > indirectly lost: 352 bytes in 4 blocks > > > in the valgrind log's summary footer, adding PASSes if they are zero > > > bytes, and, for now generating XFAILs for non-zero bytes. > > > > > > Sadly this diverges jit.exp's fixed_host_execute further from DejaGnu's > > > host_execute, but I don't see a clean way to fix that. > > > > > > This currently adds 63 PASSes and 49 XFAILs to jit.sum, giving: > > > # of expected passes 2481 > > > # of expected failures 49 > > > > > > gcc/testsuite/ChangeLog: > > > PR jit/63854 > > > * jit.dg/jit.exp (report_leak): New. > > > (parse_valgrind_logfile): New. > > > (fixed_host_execute): Detect if RUN_UNDER_VALGRIND is present > > > in the environment, and if so, run the executable under > > > valgrind, capturing valgrind's output to a logfile. Parse the > > > log file, generating PASSes and XFAILs for the summary of leaks. > > OK for the trunk. FWIW, I'd love to see a mode where we can easily do > > this for the other testsuites as well. > > Many of the cleanups in these patches are called from toplev::finalize, > or something called from there, so that they're called by libgccjit.so, > but not called by cc1/cc1plus etc. > > In general, cc1 etc don't need to bother free-ing everything, and can > instead simply exit. > > But if you're running under valgrind, you'd probably want them to call > toplev::finalize before exiting, to make the valgrind log shorter. > > So perhaps cc1 etc could detect if they're being run under valgrind, and > call toplev::finalize in the appropriate place? > > Or maybe this could be a command-line option? > > [I think I prefer autodetection, fwiw]
It turns out that this isn't necessary (I think), since the pointers are typically still reachable.
