On Thu, 19 Nov 2015, Martin Li?ka wrote: > Hello. > > In last two weeks I've removed couple of memory leaks, mainly tight to > middle-end. > Currently, a user of the GCC compiler can pass '--enable-checking=valgrind' > configure option > that will run all commands within valgrind environment, but as the valgrind > runs just with '-q' option, > the result is not very helpful. > > I would like to start with another approach, where we can run all tests in > test-suite > within the valgrind sandbox and return an exit code if there's an error seen > by the tool. > That unfortunately leads to many latent (maybe false positives, FE issues, > ...) that can > be efficiently ignored by valgrind suppressions file (the file is part of > suggested patch). > > The first version of the valgrind.supp can survive running compilation of > tramp3d with -O2 > and majority of tests in test-suite can successfully finish. Most of memory > leaks > mentioned in the file can be eventually fixed.
I didn't quite understand the need for the suppression files. Is it like Markus said, only because valgrind annotations are not on by default? Then let's change it so that's the default during DEV-PHASE = experimental (the development phase) or prerelease. I really thought that was the case by now. (The suppression files are IMHO a useful addition to contrib/ either way.) > As I noticed in results log files, most of remaining issues are connected to > gcc.c and > lto-wrapper.c files. gcc.c heavily manipulates with strings and it would > probably require > usage of a string pool, that can easily eventually removed (just in case of > --enable-valgrind-annotations). > The second source file tends to produce memory leaks because of fork/exec > constructs. However both > can be improved during next stage1. > > Apart from aforementioned issues, the compiler does not contain so many > issues and I think it's > doable to prune them and rely on reported valgrind errors. > > Patch touches many .exp files, but basically does just couple of > modifications: > > 1) gcc-defs.exp introduces new global variable run_under_valgrind > 2) new procedure dg-run-valgrind distinguishes between just passing options > to 'gd-test', > or runs 'dg-test' with additional flags that enable valgrind (using > -wrapper) > 3) new procedure dg-runtest-valgrind does the similar > 4) many changes in corresponding *.exp files that utilize these procedures > > The patch should be definitely part of next stage1, but I would appreciate > any thoughts > about the described approach? IIRC you can replace the actual dg-runtest proc with your own (implementing a wrapper). Grep aroung, I think we do that already. That's certainly preferable instead of touching all callers. > > Thank you, > Martin brgds, H-P
