Re: better -Wuninitialized (Re: Ada files now checked in)

[Diego Novillo <dnovillo at redhat dot com>]

On Sun, 07 Oct 2001, Zack Weinberg wrote:

> > - if its only reaching definition is the ghost def, the variable
> >   *is* used uninitialized.
> > 
> > - if one of its reaching definitions is the ghost def, the
> >   variable *may be* used uninitialized.
> ...
> 
> I'm not too familiar with reaching definitions, do they take control
> dependencies into account?
> 
Yes, that's what the SSA form is for:

1	  int a, b;
2	
3	  b = foo();
4	  if (b < 100)
5	    a = 10;
6	  b = b + a;

SSA will place a phi-term for A after line 5 (the first block
outisde the if-statement).  This will be a phi-term with two
arguments, one for the definition of A at line 5 and the other
for the ghost definition at line 0: phi(A) = (def(A,5), def(A, 0)).

When computing reaching definitions, the algorithm follows all
the use-def chains for every use.  The use of A at line 6 is
reached by that phi-term.  Following the phi-term arguments takes
you to def(A,5) and def(A,0).

So, you end up with the set {def(A,5), def(A,0)} as the set of
reaching definitions for A at line 6.  Since one of them is the
ghost definition, that use *may be* use uninitialized.


> It would often be helpful if an uninitialized variable could be
> automatically set to a "poison" value by the compiler.  This would
> prevent one major cause of hard-to-find context-dependent bugs.  It
> sounds like this can easily be implemented by emitting real code for
> the ghost definitions; dead code elimination would then zap it in all
> cases where there isn't a problem.  Have you considered this?
> 
Not really.  But it is definitely doable.  The only problem is
what to consider a 'poison' value.  OTOH, if the compiler is
already warning you that you're using the thing uninitialized,
why would you also need this run-time trick?


> > Also, I'm about to add def-def chains to model non-killing
> > definitions like:
> > 
> > 1: int a, b *p;
> > 2: 
> > 3: a = 4;
> > 4: *p = 3;
> > 5: b = a + 1;
> > 
> > The use of a at line 5 may be reached by the definitions of *p
> > and a at lines 4 and 3, respectively.  But this part is nowhere
> > near ready.
> 
> Hmmm... since p itself is not initialized, it seems like you'd want to
> complain about it and then assume it doesn't alias anything. 
> 
Hmm, I should've initialized p in the example.  But good point.
This would've given you a warning for *p.  De-referencing a
pointer is a use of the pointer and a def of every variable in
its equivalence set.  In this case, we could empty the
equivalence set if p is used uninitialized.



> > - Compute the SSA form.  This involves computing immediate
> >   dominators and dominance frontiers.  I believe the algorithms
> >   we have in GCC are quite quick, but I haven't really looked.
> 
> If I remember correctly we are using the state-of-the-art algorithm,
> but its use of sbitmaps may cause problems.  (looking at ssa.c - dunno
> if the same code is used for trees).
> 
In tree SSA we call calculate_dominance_info and
compute_dominance_frontiers directly.  Also, the code uses
sbitmaps quite frequently.  The bitmaps are typically
O(n_basic_blocks).  What problem are you referring to?


Diego.