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

> How do you know it is a major effort?

Changing the intermediate language is *always* a major effort,
especially in a large, complex, and mature compiler. Moreover, it's
not necessarily Gimple itself, it's the way the front-end lowers code
from C++ to Gimple, it's the way in which optimizations are structured
and scheduled, etc.  In other words, the entire compiler architecture.
 The actual analysis we do is relatively simple, so re-implementing it
in clang was by far the easier path.

Moreover, although I can describe the problems I had doing static
analysis in gcc, I can't point to any reasonable solutions.  Gcc is
good at what it does, and most of the things that were roadblocks for
me are actually important to gcc's core mission -- which is to compile
C++ programs into fast, high-quality machine code.  It's not that we
were deliberately keeping quiet, it's that these are not problems that
can be easily fixed without breaking something far more important.

Again, I would be happy to share some of our experiences with you if
you are interested.  But it's not going to change our decision.


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?
> This is why this decision is such a disappointment here because I have
> not seen one message about what needs to change to help support the
> future development of static analyzer in GCC. ?Yes people have said it
> can't be done fully currently because the AST but that does not mean
> asking the right question and answering how can we change GCC to allow
> for a better job of doing this kind of development.
> Being quiet about it and then saying it can't be done without any
> reasoning behind why moving away from GCC is seems a bit out of place.
> Thanks,
> Andrew Pinski
>> ?-DeLesley
>> On Thu, Apr 19, 2012 at 9:25 AM, Andrew Pinski <> wrote:
>>> On Thu, Apr 19, 2012 at 8:44 AM, Delesley Hutchins <> wrote:
>>>> The gcc version has been difficult to support and maintain, due mainly
>>>> to the fact that the GIMPLE intermediate language was never designed
>>>> for static analysis. ?The abstract syntax tree provided by Clang is an
>>>> easier data structure to work with for front-end analyses of this
>>>> kind. ?Moreover, the gcc implementation of annotalysis has some issues
>>>> that make an eventual merge into trunk somewhat unlikely, and
>>>> annotalysis is of little use to people outside of google as long as it
>>>> stays in google/main. ?The clang implementation has been in trunk from
>>>> the beginning.
>>>> Hope that explains it a bit better,
>>> No, that it does not help at all. ?This seems like a high level issue
>>> of the problem rather than describing the reasons why GIMPLE will
>>> never work correctly for your usage. ?Maybe we can expand it for your
>>> usage but we need to better understand what it is lacking.
>>> Thanks,
>>> Andrew Pinski
>>>> ?-DeLesley
>>>> On Thu, Apr 19, 2012 at 8:15 AM, Andrew Pinski <> wrote:
>>>>> On Thu, Apr 19, 2012 at 7:15 AM, Diego Novillo <> wrote:
>>>>>> We have decided to terminate the thread safety annotation project in
>>>>>> GCC.
>>>>>> The current implementation is in the branch google/main for those
>>>>>> interested in using it. ?We will not be pursuing a merge into trunk.
>>>>>> Instead, we have started implementing the same functionality in Clang.
>>>>> What went into making this decision? ?I know lot of folks will almost
>>>>> never go over to using clang since it means supporting one extra
>>>>> front-end. ?I am thinking of the embedded folks here where they cannot
>>>>> afford supporting something as new as clang for their customers.
>>>>> Thanks,
>>>>> Andrew Pinski
>>>>>> I've updated the wiki page and moved the branch out of the active
>>>>>> development branches in svn.html.
>>>>>> Diego.
>>>> --
>>>> DeLesley Hutchins | Software Engineer | | 505-206-0315
>> --
>> DeLesley Hutchins | Software Engineer | | 505-206-0315

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]