> 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 <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 -- DeLesley Hutchins | Software Engineer | deles...@google.com | 505-206-0315