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));