On Thu, Jan 27, 2011 at 5:08 AM, Richard Guenther <richard.guent...@gmail.com> wrote: > On Thu, Jan 27, 2011 at 1:23 PM, Laurynas Biveinis > <laurynas.bivei...@gmail.com> wrote: >> The --enable-checking=valgrind does two things. First, it provides >> Valgrind annotations for internal GCC allocators so that Valgrind has >> a better idea about memory blocks which are not supposed to be >> accessed. Second, it actually invokes Valgrind on every compiler >> invocation. This makes the option very nice for e.g. ensuring that >> bootstrap and testsuite are Valgrind-clean. However if one wants to >> use Valgrind only to analyze a particular testcase, then the price of >> full Valgrind'ified bootstrap is prohibitive. >> >> Thus I propose to separate the two. To avoid introducing another >> --enable-checking option, let's move the annotations to the "misc" >> checking and also enable "misc" too if "valgrind" is requested. Both >> these options are disabled for releases, so no performance loss there. >> >> There are two drawbacks I can think of. First, if one wants Valgrind >> annotations but does not have the required headers, then the compiler >> will be built without them - silently (currently >> --enable-checking=valgrind fails if headers are not found). Second, >> the compiler binary will be built slightly different if "misc" is >> enabled depending on the presence or absence of those headers. I >> believe these are minor enough. >> >> I have a prototype patch which I've been using on gc-improv (not >> committed there yet). >> >> What do you think? > > I think we should drop the behavior that --enable-checking=valgrind > invokes valgrind, this seems like an odd feature. Doing the annotations
I think it is useful. I have run --enable-checking=valgrind once and it took daaaaaaaaaays to finish. But I haven't got time analyze the result. -- H.J.
