This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] GCC caret diagnostics
On 13/03/2008, Ian Lance Taylor <iant@google.com> wrote:
> Tom Tromey <tromey@redhat.com> writes:
>
>
> > I'm not certain that this is the tradeoff I prefer, but I haven't
> > exactly done a survey of what diagnostics are emitted where. My
> > general worry is that these more distant (from the FE) diagnostics
> > will also be the ones where having good location information would be
> > the most useful.
>
>
> As Chris and others have argued, we can do uninitialized warnings in
> the frontend.
Chris also commented that clang has a call graph, dataflow and static
analysis in the front-end. This is a fundamental difference and
explains why their uninitialized warnings wouldn't be annoyingly
noisy. That is not the case in GCC. Our warnings will be very noisy
because we would warn for things like:
int foo()
{
int i;
int j;
do {
j = bar (i);
i++;
} while (i < j);
return j;
}
And countless other examples. GCC itself would need to initialize a
bunch of variables (I think they were around 100), last time I tried
to bootstrap with such change. We would better remove -Wuninitialized
from -Wall in that case.
> I agree in general that for middle-end warnings having good location
> information is useful. The problem is that for warnings like the
> undefined overflow warnings good location information is quite
> difficult. 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.
Well, we will have to live with that then. But currently we are giving
a line number (and a column number if -fshow-column) and that is
pointing to something, so I guess that we can always display a caret
for that thing.
Cheers,
Manuel.