Chris Lattner <[EMAIL PROTECTED]> writes: > 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.
Yes. We implemented the undefined overflow warning because some people were concerned about gcc's behaviour with regard to optimizing based on undefined overflow. That is, it was done at user request. Users who do not know how to deal with the warning should correctly turn it off and use -fwrapv to avoid the problem in their code. In fact, in general I think that is true even without really good location info. As I said, right now we have a statement location for these sorts of warnings. The question here is how much more helpful it will be, in the simple cases, if the warning can point to a precise location within the statement. I'm a little bit skeptical because I don't think that for most people this warning is nearly incomprehensible (the warning was put in at user request, under the threat of having autoconf disable some gcc optimizations if the warning was not present). That said, I'm certainly not opposed to doing some work to get better location information if possible. In the tuples world we have to think seriously about whether we want to carry that additional location information through the middle-end. It's a real cost; is it worth it? Ian
