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: Announce - Thread safety annotations no longer supported in GCC

Diego is right.  Clang maintains an accurate C++ AST, and then layers
additional data structures, like the control flow graph, on top of
that, so you don't get the same kind of lowering artifacts that have
plagued the gcc implementation of annotalysis.  That architecture
makes Clang a much better platform for static analysis.

However, I want to point out that Gimple is actually designed pretty
well, especially considering the fact that it was never intended to be
a source code analysis framework.  Certain parts of our analysis were
much easier to do in Gimple than in Clang, because we could leverage
the work of previous transformations (e.g. lowering to SSA).  However,
those same transformations made some other parts of the analysis
nearly impossible.  There is no such thing as a perfect intermediate
language that will satisfy everyone.


considering that Gimple was never intended to be a source code analysis

On Thu, Apr 19, 2012 at 1:20 PM, Diego Novillo <> 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.
> Diego.

DeLesley Hutchins | Software Engineer | | 505-206-0315

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