http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #6 from Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> --- (In reply to Kostya Serebryany from comment #5) > > That's great... works even for Fortran code :-) > Wow! well, many thanks to those people making sanitizer happen, also in gcc. > > In performance-critical scenarios, LSan can also be used without ASan > > instrumentation. > > > > But it is unclear from that description how that would work.. any hints ? > > Clang supports -fsanitize=leak which simply links a standalone lsan library > (no instrumentation at compile time required). > Perhaps gcc can add such option too. I agree that such an option would be useful (see also below). For now, I put '-fsanitize=address' for the link step only, which has the same effect. Additionally, it seems important to have -g -fno-omit-frame-pointer in the options. Maybe gcc should add these options for best 'user experience', for example as part of -fsanitize=address/leak. Power users can always override with -fsanitize=leak -fomit-frame-pointer. > But: we do not test -fsanitize=leak on anything other than tiny tests, > so we truly support only the lsan+asan use case. It would be great to have -fsanitize=leak robust. For our testing purposes we can not have the overhead of -fsanitize=address (which for Fortran is largely, but not completely, covered by -fcheck=bounds). Anyway, first test on our codebase (~1Mloc) suggests it works well (modulo PR59063). I'll add -fsanitize=x to my nightly gcc trunk tester. > We'll need to update the wiki page to have this all explained in detail, > thanks for raising these questions. One more example for the wiki, that's how we can run this with cp2k ;-) time ASAN_OPTIONS="detect_leaks=1" ../../exe/Linux-x86-64-leaks/cp2k.sdbg C.inp 2>&1 | python /data/vjoost/gnu/bugs/asan_symbolize.py
