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