[Bug bootstrap/96404] [10 Regression] Bootstrap failure

slyfox at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Sun Aug 2 10:56:16 GMT 2020


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.


More information about the Gcc-bugs mailing list