This is the mail archive of the 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

On 13/03/2008, Chris Lattner <> wrote:
>  On Mar 12, 2008, at 5:07 PM, Manuel López-Ibáñez wrote:
>  > On 08/03/2008, Chris Lattner <> wrote:
>  >>
>  >> 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.
>  >
>  > So no warnings for uninitialized variables?
> The clang front-end generates these warnings.  This means that the set
>  of warnings produced by the compiler doesn't change as the optimizer
>  evolves, are generally less mystifying to the user, and have perfect
>  location info as a side effect.  People who use -Werror tend to prefer
>  when they don't get new random warnings due to a compiler upgrade.
>  This approach is similar to what Java compilers do and frontends like
>  EDG do (afaik).

But then you don't have constant propagation and other optimisations
that remove fail positives, do you? Well, we have discussed already
doing all uninitialized warnings  before optimisation but users do
complain about false positives.

For example:

func2 (int cond)
    int x;
    int flag = 0;

        x = 1;
        flag = 1;



>  The Clang project is also growing a static analysis engine which is
>  very adept at solving path sensitive versions of these problems, which
>  is useful for finding deeper bugs.

I guess that must take considerably more time and resources and be
redundant with some of the work of the optimisers. I guess we cannot
use such approach in GCC.



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