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 20:49 +0900, Neil Booth wrote:

I think this is a better approach than the current one, and that if we go down this patch then we should grasp the opportunity to do it right - the early pass should be in the front end. Let the optimizers do the fancy cases. 90% of cases that catch bugs can be handled in the front end I expect, with a very simple algorithm. I don't think we want/need to catch any cases in the front-end. One of the nice things about our SSA form is the algorithm for uninitialized uses is very very simple.

An uninitialized use is trivially detected as any use in the IL which refers to the "default definition" of a variable.

If the use occurs in a real statement, then what we have is a use in which no paths through the CFG which reach the use ever define the variable in question.

If the use occurs in a PHI node, then what we have is a use which might be uninitialized depending on whether or not a particular edge in the CFG can be traversed at runtime.

This simplicity is a natural side effect of our SSA form.

The complications are merely an artifact of where in the optimization pipeline we choose to issue warnings. The exact same code can be used to satisfy either end of the desired warning spectrum -- all that changes is whether or not the maybe-uninitialized warning code fires early or late in the optimization pipeline.

Moving the warning into the front-end just adds unnecessary complexity to the problem and more code to maintain.

Jeff

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