This is the mail archive of the
mailing list for the GCC project.
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.
> > 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;
> 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.