This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug rtl-optimization/33796] valgrind error with -O2 for linux kernel code
- From: "bergner at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 17 Oct 2007 04:46:54 -0000
- Subject: [Bug rtl-optimization/33796] valgrind error with -O2 for linux kernel code
- References: <bug-33796-9596@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- 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.
--
bergner at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33796