[Bug rtl-optimization/33796] valgrind error with -O2 for linux kernel code

["zadeck at naturalbridge dot com" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #3 from zadeck at naturalbridge dot com  2007-10-17 11:25 -------
Subject: Re:  valgrind error with -O2 for linux
 kernel code

bergner at gcc dot gnu dot org wrote:
> ------- Comment #2 from bergner at gcc dot gnu dot org  2007-10-17 04:46 -------
> Although valgrind is correct that we are doing an uninitialized read, the code
> is actually working as designed and is correct.
>
> When we allocate a sparseset, we only need to set set->members to 0 to clear
> the set.  The arrays set->sparse[] and set->dense[] are not and do not need to
> be initialized.  To test a value "n" for membership in "set", it needs to
> statisfy two properties:
>
>    set->sparse[n] < set->members
>
> and
>
>    set->dense[set->sparse[n]] == n
>
> The uninitialized read occurs when "n" is not (and never has been) a member of
> "set".  In this case, set->sparse[n] will be uninitialized and could be any
> value.  If set->sparse[n] happens to be >= set->members, we luckily (but
> correctly) return that "n" is not a member of the set.  If the uninitialized
> set->sparse[n] is < set->members, we continue on to verify that
> set->dense[set->sparse[n]] == n.  This test cannot be true since all
> set->dense[i] entries for i < set->members are initialized and "n" is not a
> member of the set.  So yes we do some uninitialized accesses to the sparse
> array, but that's ok.  It's also a benefit of sparseset, given that we don't
> have to memset/clear the whole sparseset data structure before using it, so
> it's fast.
>
>
>   
peter,

i think that this is clever and nice but it is not going to fly.  people
will be running valgrind and this will hit them over and over again. 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33796