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] Thoughts? Dave
