Jeffrey A Law - Re: -Wuninitialized issues (original) (raw)

This is the mail archive of the gcc@gcc.gnu.orgmailing 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]
Other format: [Raw text]

On Tue, 2005-11-01 at 10:32 -0800, Joe Buck wrote:

On Tue, Nov 01, 2005 at 11:17:52AM -0700, Jeffrey A Law wrote:

On Tue, 2005-11-01 at 11:06 -0500, Diego Novillo wrote:

To prevent losing location information for the warning, I had modified the propagation engine to warn as it folded the expression away. Possibly a useful thing to have, but I don't think we want to put the burden of detecting uninitialized variables onto each optimizer :-)

Just an off-the-wall idea: What if dereferencing an uninitialized variable is considered a side effect? Then that side effect must be preserved unless it is unreachable. Consider

   while (i > 0)
      i--;
   // no more uses of i.

Instead of throwing everything away, this would become

__check_initialized(i);

and we would still get the warning. I think that solves a subset of the stuff we're discussing, but I don't think it's general enough. Consider a variable which is used in a statement and the result of that statement is never used. ie

foo(int a) { int i, x;

x = a; x += i; }

Or unreachable code issues:

foo() { int i;

if (0) i++;

i = ... more code... }

I think that picking one of the alternatives I outlined a few minutes ago will take us to a better place without resorting to these kind of tricks.

In my mind it's more a matter of determining what behavior we want. Once we've selected the desired behavior, achieving that behavior with the basic framework we've already got is pretty straightforward (unless we are determined to try and solve the halting problem :-)

Jeff

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