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

"Manuel LÃpez-IbÃÃez" <> writes:

>>  >>  Another approach would be to only use the carets for parse errors,
>>  >>  which is where they are the most helpful.  For a middle-end error like
>>  >>  "assuming signed overflow does not occur when simplifying
>>  >>  multiplication" a caret pointer might be more misleading than
>>  >>  otherwise, as one thing we know for sure is that it would not point at
>>  >>  a multiplication operator.
>>  >>
>>  >
>>  > I don't get this. So, what is it pointing to?
>> I don't know for sure.  I would guess that it would point to the start
>>  of the statement in which the overflow is found.  The warning is going
>>  to use the location from some statement being simplified, not from the
>>  operator.
> Why? Isn't the operator available at that point?

The location information, if present, is technically available, but it
would require some surgery to actually get it.  The warning is queued
up in fold_binary, which does not have access to the location and is
often called in cases where there is no obvious location--because it
is optimizing some other expression.  The warning is not issued at
that point.  It is only issued later, when we know whether the folding
caused some actual simplification in the statement.  At that point we
also don't know the specific location.

As we move to tuples, we will have even less location information at
this point.  We will almost certainly not have the location of any
operators.  This is in general a good thing, as we won't be paying the
memory space to carry them through the whole middle-end.


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