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, Chris Lattner <clattner@apple.com> wrote:
>
> There is no right answer, and this topic has been the subject of much
> debate on the GCC list in the past. I really don't care to debate the
> merits of one approach vs the other with you, I just answered your
> question about what clang does.
Of course. I didn't want to get into a debate. I was just trying to
figure out how clang addressed the problem of false positives (or
alternatively the problem of users complaining about them). Thanks for
taking the time to elaborate.
> Amusingly, GCC 4.0 emitted a false positive about this example despite
> using the techniques you discuss, and no GCC emits any of these
> warnings at -O0 (which is a very common mode used when doing a
> majority of development for some people).
Oh, we certainly do worse than that. See PR 179. I hope you didn't
interpret my comments as criticism of LLVM. Certainly all approaches
have its drawbacks and the one in GCC have a lot of drawbacks plus
deficiencies.
> I have no opinion about the approach that you take in GCC. In
> practice, we have been able to do this analysis very quickly and get
> good results, and will continue to refine them as clang continues to
> mature.
Hum, that is very interesting because doing these warnings in the
middle-end causes so many false positives/negatives anyway that
perhaps a limited static analysis in the front-end achieves better
results. And the only argument then would be the overhead of the
static analysis. If that is not an issue either, then it seems a very
attractive approach indeed.
Do you use the static analysis for other things (other warnings, early
optimizations/folding)? There are many other warnings that would be
noticeably enhanced by some dataflow in the front-end.
> I personally think that it is a major problem that GCC doesn't produce
> these diagnostics unless optimizations are enabled, and I continue to
> think that having diagnostics change depending on what optimization
> level is enabled is bad.
I think everybody agrees on both. Yet the alternatives to these issues
right now in GCC are building SSA at -O0 and moving the warnings
earlier in the pipeline, respectively. The former results in
slower/bigger -O0 compiler. Both would generate much more false
positives, and there have been a few patches proposing moving them
even later to avoid some false positives.
I guess the static analysis in the front-end was discarded because of
compile-time concerns, but if you don't see that (and clang seems to
be much faster than GCC), then it may be worth reconsidering it.
Cheers,
Manuel.