On Thu, Mar 13, 2008 at 02:39:25PM -0700, Chris Lattner wrote: > On Mar 13, 2008, at 11:37 AM, Ian Lance Taylor wrote: > > As you know the optimizers can pull together information > >from all over the place. The actual warning can be issued for code > >which looks very different from anything the user actually wrote. > >Translating back to the problem in the user code can be complicated. > >I don't think gcc is going to be able to do that translation. > > While this is absolutely true, think about what you're saying here. > Roughly categorized, there are two cases that happen: > > 1. The problem is relatively simple and doesn't require deep analysis > to identify and explain to the user. > 2. The problem is subtle, requiring multiple levels of optimizer to > interact correctly to find the problem. > > In case #1, you can have good location info and use cheap techniques > for finding the problem. If you do this and tell the user, they are > likely to understand and fix the problem. > > In case #2, even if you find an obscure (and real!) bug, without > *really* good location info, there is a very low likelihood that the > user will understand it. It's more likely that they will turn off the > warning or file a GCC bug.
In the case of an unitialized variable, accurate warnings require good dataflow analysis that can handle correlated variables; something like gated SSA might be needed to prevent false warnings about paths that are infeasible because of flags in the code. But once the issue is found, simply naming the variable and the file/line where it is declared suffices to inform the user.
