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

Reply via email to