[RFC] GCC caret diagnostics

[Chris Lattner]

On Mar 7, 2008, at 6:06 PM, Ian Lance Taylor wrote:

> Tom Tromey <tromey@redhat.com> writes:
>
>> Ian suggested that we delete this information after the FE is
>> finished.  This makes sense, I think, from a memory-saving
>> perspective.  But, that means we will get different kinds of error
>> output depending on when a diagnostic is emitted, which I think is
>> pretty unfriendly -- it exposes implementation details of gcc to the
>> user.
>
> I think that is mostly OK in practice because most diagnostics are
> issued by the front end.  But I admit that some come from the
> middle-end, so there would be an inconsistency.
>
> 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.

An important class of middle-end warnings is use of undefined values  
and other dataflow warnings in GCC.

> What do other compilers do?  Reopening the file doesn't work for
> standard input, which I admit is an unusual case.

clang points into the original input buffer that was lexed from.  This  
requires keeping the original files mapped into the address space of  
the compiler.  However, clang only produces diagnostics from the front- 
end, not from the middle-end.

-Chris