This is the mail archive of the
mailing list for the GCC project.
Re: Announce - Thread safety annotations no longer supported in GCC
On Thu, Apr 19, 2012 at 10:30 AM, Delesley Hutchins <email@example.com> wrote:
> I can give you detailed technical reasons why GIMPLE was not working
> for us if you like, but I'm not sure it would be all that
> constructive. ÂWe have already made the decision to switch to clang
> for annotalysis users within google, for reasons that are only partly
> technical. ÂThe only reason to support the gcc version would be if
> there was sufficient interest in annotalysis outside of google to
> warrant the effort of moving it to trunk. ÂGiven that the annotalysis
> branch stopped tracking trunk almost a year ago, and has been disabled
> in even in google/main for the past 6 months, I would be surprised to
> find any such users. ÂSince the estimated number of users is currently
> zero, there seems little point in maintaining the software.
> Moreover, although I appreciate your offer to try and expand GIMPLE, I
> don't think it makes a lot of sense. ÂGIMPLE works just fine for its
> intended use case, which is an intermediate language for compiler
> optimization. ÂChanging GIMPLE would be a major effort, and it would
> only be warranted if there were enough users to make it worthwhile.
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?
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.
> On Thu, Apr 19, 2012 at 9:25 AM, Andrew Pinski <firstname.lastname@example.org> wrote:
>> On Thu, Apr 19, 2012 at 8:44 AM, Delesley Hutchins <email@example.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.
>> Andrew Pinski
>>> On Thu, Apr 19, 2012 at 8:15 AM, Andrew Pinski <firstname.lastname@example.org> wrote:
>>>> On Thu, Apr 19, 2012 at 7:15 AM, Diego Novillo <email@example.com> wrote:
>>>>> We have decided to terminate the thread safety annotation project in
>>>>> 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.
>>>> Andrew Pinski
>>>>> I've updated the wiki page and moved the branch out of the active
>>>>> development branches in svn.html.
>>> DeLesley Hutchins | Software Engineer | firstname.lastname@example.org | 505-206-0315
> DeLesley Hutchins | Software Engineer | email@example.com | 505-206-0315