This is the mail archive of the gcc@gcc.gnu.org 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.

Thanks.

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

Cool.

zw


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