This is the mail archive of the gcc@gcc.gnu.org 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


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.  It has a downside: Chris commented that the optimizers
can emit confusing uninitialized warnings with many layers of
inlining.  I've seen that myself.  But I've seen correct warnings that
way--the variable really was uninitialized.  So moving the warnings to
the tradeoff has a simple tradeoff: you miss some correct warnings.

The warnings we can not do in the frontend are the warnings about
aliasing violations and reliance on undefined overflow.  At least, I
don't see any way to do those reliably without using the optimization
machinery.  I think most other warnings could move to the frontend if
we so desired.

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.

Ian


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