On Wed, 2005-11-02 at 18:02 -0800, Mark Mitchell wrote:
> Jeffrey A Law wrote:
>
> > For example, if the only use was inside an unreachable hunk of
> > code, does that count as a use or not?
>
> Yes, the EDG front-end does this:
>
> [EMAIL PROTECTED]:~/tmp$ cat test.cpp
> void f() {
> int i;
> if (0)
> i = 3;
> }
> [EMAIL PROTECTED]:~/tmp$ eccp -A test.cpp
> "test.cpp", line 2: warning: variable "i" was set but never used
> int i;
Well, if we wanted to do something that simplistic, it's just a walk
over the IL :-) Two bits. One if we've seen a set for the variable,
the other if we've seen a use.
> (Wouldn't it be easy to emit a warning for this in GCC, in the same
> optimization-based way we do uninitialized warnings? If there are no
> paths from the block with the assignment to a use, then the store is
> useless.)
It wouldn't be terribly hard. It's just DCE with some additional
bookkeeping.
FWIW, I have come across a case where we're still going to have
inconsistencies in our uninitialized warnings, even with the
new -Wuninitialized=2 bits.
We do not give uninitialized warnings for objects which live in
memory. So for example if a variable's address is taken, then we
do not attempt to give an uninitialized warning for it.
However, our optimizers _may_ remove the need for taking the
variable's address. If that happens, then the new variable is
exposed and we'll do the uninitialized analysis after optimization
is complete.
So there's still going to be cases where we can get inconsistent
results from one release to the next. Ugh.
I also mis-read the passes.c code, we do not build the SSA form
unless we are optimizing. So we still need -O to get uninitialized
warnings. I think we can address that separately.
I've put a possible patch in the metabug (24639). As I mention in
the comments, I'm not comfortable self-approving it given my lack of
knowledge about the option processing code and the debate over what
we want the default -Wuninitialized behavior to be.
jeff
