var-tracking: fix uninitialised use of 'in_pending' [PR96404]
r11-2447-g:1212cfad093 ("Improve var-tracking dataflow iteration order") changed 'in_pending' initialization from: in_pending = sbitmap_alloc (last_basic_block_for_fn (cfun)); bitmap_ones (in_pending); to more complex partial bit population algorithm. Due to presence of uninitialized bits gcc started injecting extra debug entries in seemigly arbitrary locations and started failing stage2/stage3 bootstrap comparison. valgrind detected unilitialized bits as: Conditional jump or move depends on uninitialised value(s) at 0xDBED3B: vt_find_locations() (var-tracking.c:7230) by 0xDBF2FB: variable_tracking_main_1() (var-tracking.c:10519) ... Uninitialised value was created by a heap allocation at 0x483779F: malloc (vg_replace_malloc.c:307) by 0x14EE80B: xmalloc (xmalloc.c:147) by 0x14911F9: sbitmap_alloc(unsigned int) (sbitmap.c:51) ... The fix explicitly initializes 'in_pending' bitmap with zeros. 2020-08-02 Sergei Trofimovich <siarheit@google.com> gcc/ PR bootstrap/96404 * var-tracking.c (vt_find_locations): Fully initialize all 'in_pending' bits.
This commit is contained in:
parent
b3b2bf98ff
commit
6e46b3f3da
1 changed files with 1 additions and 0 deletions
|
@ -7096,6 +7096,7 @@ vt_find_locations (void)
|
|||
in_worklist = sbitmap_alloc (last_basic_block_for_fn (cfun));
|
||||
in_pending = sbitmap_alloc (last_basic_block_for_fn (cfun));
|
||||
bitmap_clear (in_worklist);
|
||||
bitmap_clear (in_pending);
|
||||
|
||||
/* We're performing the dataflow iteration independently over the
|
||||
toplevel SCCs plus leading non-cyclic entry blocks and separately
|
||||
|
|
Loading…
Add table
Reference in a new issue