http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54783
Marek Polacek <mpolacek at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek <mpolacek at gcc dot gnu.org> 2012-10-03 06:34:18 UTC --- Not a bug, probably. Valgrind ought to be used only when --enable-checking=valgrind. Otherwise we have to live with those sparseset warnings, as those valgrind markups aren't compiled in. The thing is in gcc-4.7 sparseset_alloc we have: /* We use xcalloc rather than xmalloc to silence some valgrind uninitialized read errors when accessing set->sparse[n] when "n" is not, and never has been, in the set. These uninitialized reads are expected, by design and harmless. If this turns into a performance problem due to some future additional users of sparseset, we can revisit this decision. */ sparseset set = (sparseset) xcalloc (1, n_bytes); But in trunk sparseset_alloc there's: sparseset set = XNEWVAR(struct sparseset_def, n_bytes); /* Mark the sparseset as defined to silence some valgrind uninitialized read errors when accessing set->sparse[n] when "n" is not, and never has been, in the set. These uninitialized reads are expected, by design and harmless. */ VALGRIND_DISCARD (VALGRIND_MAKE_MEM_DEFINED (set, n_bytes));