This is the mail archive of the mailing 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]

Re: [RFC] GCC caret diagnostics

Chris Lattner <> 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.


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?


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