Re: Announce - Thread safety annotations no longer supported in GCC

[Richard Guenther <richard.guenther@gmail.com>]

On Thu, Apr 19, 2012 at 10:20 PM, Diego Novillo <dnovillo@google.com> wrote:
> On 4/19/12 4:14 PM, Andrew Pinski wrote:
>
>> How do you know it is a major effort?  Has any issues related to
>> changing Tuple/front-ends AST been raised to the mailing list and
>> asked for help on how to implement these changes?
>
>
> The kind of analysis that Annotalysis needs cannot be catered by GIMPLE, the
> same way that LLVM's bitcode could not cater to it.  Both representations
> are geared towards code transformations, not source code analysis.  It's not
> an implementation issue, but a design one.  It simply does not make sense
> for GIMPLE or LLVM's bitcode to try to be a source code analysis framework.
>
> Annotalysis needs a high-fidelity representation of the original source
> code.  Today, that high-fidelity representation is provided exclusively by
> Clang.
>
> Additionally, we are already supporting Clang as a front end to provide
> syntax and semantic analysis.  Given that Clang provides a much more
> flexible framework for static analysis, the decision was a relatively simple
> one.
>
> This is not to say that Clang provides everything needed by Annotalysis.
>  There is some need to use dataflow information which needs to be
> incorporated in Clang.  However, a large fraction of the support required
> was already available in Clang.

Our high-level AST is language specific.  In case of C++ its GENERIC plus
some C++ specific tree codes.  There is no framework for building a CFG
on top of that (not sure if you need that), but the cgraph is built over that
representation.

Of course non-optimizing ASTs will limit static analysis to TU scope, even
with clang?  Or does clang support a "LTO" source AST?

Richard.

>
> Diego.