This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug rtl-optimization/54783] [4.8 Regression] valgrind reports using uninitialised data in mark_pseudo_regno_live and make_object_born on basic code


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]