[RFC] GCC caret diagnostics

[Manuel López-Ibáñez]

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.