On 13/03/2008, Chris Lattner <[EMAIL PROTECTED]> wrote:
>
> On Mar 12, 2008, at 5:07 PM, Manuel López-Ibáñez wrote:
>
> > On 08/03/2008, Chris Lattner <[EMAIL PROTECTED]> 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:
void
func2 (int cond)
{
int x;
int flag = 0;
if(cond)
{
x = 1;
flag = 1;
}
foo();
if(flag)
use(x);
}
> 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.
Cheers,
Manuel.
