This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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

On Sun, Oct 07, 2001 at 01:21:01PM -0400, Diego Novillo wrote:
> On Sun, 07 Oct 2001, Zack Weinberg wrote:
> > Maybe you could change the warning message to "...used uninitialized
> > here" or "at this point" or something like that?  Just to be clear
> > it's not the same old "somewhere in the function" message.
> > 
> Sure.


> > I notice it says "_is_ used uninitialized".  Does that mean you've
> > eliminated the old false positive problems?
> > 
> That's the intent.  The new code still spews out false positives,
> that's what I'm now working on.
> The analysis depends on the computation of reaching definitions.
> Prior to computing the SSA form, we insert ghost definitions for
> every symbol in the entry basic block.  After reaching
> definitions, we traverse all the variable use references in the
> function.  For every use:
> - 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?

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?

> 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. 

> - 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).

> > It'd be nice if we could generate the warnings with
> > optimization off; that's always been a wart.
> >
> Definitiely possible.  We only need to make -Wuninitialized
> trigger -ftree-ssa.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]