https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96404
--- Comment #15 from Sergei Trofimovich <slyfox at gcc dot gnu.org> --- (In reply to Sergei Trofimovich from comment #14) > (In reply to Sergei Trofimovich from comment #9) > > valgrind says there is use of uninitialized variable: > > I picked _gcov.c and minimized it's unstable compilation under cvise. Then > minimized it under presence of warnings related to var-tracking. Here is the > minimized example: > > $ cat _gcov.c > int a; > int b(void) { > for (;;) > for (; a;) > for (unsigned c; c < b; c++) > ; > } > > $ valgrind --trace-children=yes --track-origins=yes --num-callers=50 --quiet > stage3-gcc/xgcc -Bstage3-gcc -O2 -g -o _gcov-s3.S -DL_gcov -S _gcov.c > > ==913420== Conditional jump or move depends on uninitialised value(s) > ==913420== at 0xDBDABB: vt_find_locations() (in > /home/slyfox/tmp/portage/sys-devel/gcc-11.0.0_pre9999/work/build/stage3-gcc/ > cc1) > ... The following patch seems to fix use of uninitialized variable: --- a/gcc/var-tracking.c +++ b/gcc/var-tracking.c @@ -7089,20 +7089,21 @@ vt_find_locations (void) auto_vec<std::pair<int, int> > toplevel_scc_extents; int n = rev_post_order_and_mark_dfs_back_seme (cfun, single_succ_edge (ENTRY_BLOCK_PTR_FOR_FN (cfun)), exit_bbs, true, rc_order, &toplevel_scc_extents); for (i = 0; i < n; i++) bb_order[rc_order[i]] = i; 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 over the tail. That ensures best memory locality and the least number of visited blocks. */ unsigned extent = 0; int curr_start = -1; int curr_end = -1; do { Don't know if the change correct or papers over the problem. Looking at the initialization of 'in_pending' right below it does not seem to assume full 'in_pending' initialization. I'll check if it fixes bootstrap for me.