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

[Delesley Hutchins <delesley@google.com>]

> 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.

  -DeLesley

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 <pinskia@gmail.com> wrote:
>>> On Thu, Apr 19, 2012 at 8:44 AM, Delesley Hutchins <delesley@google.com> 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 <pinskia@gmail.com> wrote:
>>>>> On Thu, Apr 19, 2012 at 7:15 AM, Diego Novillo <dnovillo@google.com> 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 | delesley@google.com | 505-206-0315
>>
>>
>>
>> --
>> DeLesley Hutchins | Software Engineer | delesley@google.com | 505-206-0315



-- 
DeLesley Hutchins | Software Engineer | delesley@google.com | 505-206-0315