From mboxrd@z Thu Jan  1 00:00:00 1970
From: craig@jcb-sc.com
To: zack@rabi.columbia.edu
Cc: craig@jcb-sc.com
Subject: Re: Uninitialized variable warnings
Date: Wed, 31 Mar 1999 23:46:00 -0000
Message-ID: <19990315211232.23607.qmail@deer>
References: <199903151256.HAA08065@blastula.phys.columbia.edu>
X-SW-Source: 1999-03n/msg00517.html
Message-ID: <19990331234600.lxj7rDtXWMkREkFAYezLXaqF3FclEc1QM6l8vKLGPzI@z>

>On 15 Mar 1999 10:39:33 -0000, craig@jcb-sc.com wrote:
>>>There are a number of other places where gcc has gotten it wrong, and
>>>a few places where the warning indicates a real bug.  There's also one
>>>worrisome case, where we get it right or not unpredictably:
>>>
>>>if(x == THING_1) var = val1;
>>>else if(x == THING_2) var = val2;
>>>else if(x == THING_3) var = val3;
>>>...
>>>else abort();
>>>...
>>>use(var);
>>
>>Could you be more precise about "unpredictably"?  Specifically, do you
>>mean it's unpredictable all the way down to identical chunks of code
>>(in separate functions, say) compiled a *single* time?  Or across
>>multiple runs of the exact same compiler?  Or do you just mean it's
>>unpredictable across compiler targets (which might be explained by
>>differences in whether abort() is known to have its noreturn attribute)?
>
>I mean that given two similar chunks of code one will get a warning
>and the other won't, and the significant difference may seem to be
>absolutely irrelevant as far as a human is concerned.  A good example
>is the `plist' variable in objc-act.c:generate_protocol_list.  We warn
>on that.  Prune everything else out of the function, and the compiler
>doesn't warn anymore.

Hmm, so it's possible there's an uninitialized-variable bug in the
compiler, but it might just be that the uninitialized-variable analysis
(including all RTL transforms that precede it) is overly sensitive
to things that would normally be thought of as irrelevant to the
issue of whether a particular variable is initialized.

>The compiler is consistent across multiple runs on the same code.

If that hadn't been the case, I'd recommend finding the (very likely)
uninitialized-variable bug ASAP, which is why I asked.

>Header file issues are a red herring - abort() is hardwired as
>noreturn in c-decl.c.

Ah, okay.

I guess your analysis means that there's probably no "obvious" solution
to the problems of unpredictability you're seeing.  But it seems worth
investigating anyway.  (I haven't got a real strong opinion regarding
when the warnings should be given.  One school of thought would be that
they're just for when the compiler detects a possible problem, so the
better it can be at "proving" no possible problem, the fewer warnings
and, probably, the better it can do at optimizing.  Another school of
thought would be that they're for improving code readability, so
programmers don't have to do code-analysis contortions a la a compiler
to figure out whether a variable is actually used before being defined,
which would imply that it's okay for the compiler to warn in provably
"spurious" cases that aren't *easy* to prove.)

        tq vm, (burley)