On Thu, Apr 19, 2012 at 10:30 AM, Delesley Hutchins <deles...@google.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. Thanks, Andrew Pinski > > -DeLesley > > On Thu, Apr 19, 2012 at 9:25 AM, Andrew Pinski <pins...@gmail.com> wrote: >> On Thu, Apr 19, 2012 at 8:44 AM, Delesley Hutchins <deles...@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 <pins...@gmail.com> wrote: >>>> On Thu, Apr 19, 2012 at 7:15 AM, Diego Novillo <dnovi...@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 | deles...@google.com | 505-206-0315 > > > > -- > DeLesley Hutchins | Software Engineer | deles...@google.com | 505-206-0315
