From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1336 invoked by alias); 19 Apr 2012 20:55:33 -0000 Received: (qmail 1327 invoked by uid 22791); 19 Apr 2012 20:55:32 -0000 X-SWARE-Spam-Status: No, hits=-5.8 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail-yx0-f175.google.com (HELO mail-yx0-f175.google.com) (209.85.213.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 19 Apr 2012 20:55:15 +0000 Received: by yenm3 with SMTP id m3so5190151yen.20 for ; Thu, 19 Apr 2012 13:55:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=Y2EGUjwIxJJ5xtojsjAcM/mAtEE9vZFHt+ybNoZ/fII=; b=X1K2zZ66UFX275bF3AxclKoWf9BXnZS5Vp6Wrx1iiaLA4pZ+9UcAfD9uRCCaq8C/1Y lPFGA09vjH1xw3QZkD2sHzmlhKee/zrYAjC0bhnfGHc+Eqc49kI1nHnnWJd1OjI6b1GE HPzIlL84FONEf8pC3N/QSYVBsT4mqPoMheCqmIH6hW4KDOOO5WJ1YPOtEG034N+arFEx ew3zmwCi53+ubnkoMUMMy0Zn9+RNInZIukYke6eD7OH8h8v09Ub/5HeEwifaQQTtFAEY RCtcz9A9D76FtVhpcLtvXbdk4Xx3H8y6f1oewh98v7R4Pt5qxHrnmDeBJHiWujppxFR8 q3sQ== Received: by 10.60.169.165 with SMTP id af5mr5031249oec.72.1334868914551; Thu, 19 Apr 2012 13:55:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.169.165 with SMTP id af5mr5031239oec.72.1334868914438; Thu, 19 Apr 2012 13:55:14 -0700 (PDT) Received: by 10.182.245.17 with HTTP; Thu, 19 Apr 2012 13:55:14 -0700 (PDT) In-Reply-To: References: <4F901DEA.1060401@google.com> Date: Thu, 19 Apr 2012 20:55:00 -0000 Message-ID: Subject: Re: Announce - Thread safety annotations no longer supported in GCC From: Delesley Hutchins To: Andrew Pinski Cc: Diego Novillo , gcc , Ollie Wild , Le-Chun Wu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQmJ0ZB+lRDFQo5VasmFq+QUAiRXuXKEVFCUtqm0YhGLPZ8fJ46ukUOJlxs5LSC6TidgGjNOkEPvUB6wnYzaRASHzeQkN9+3lMD/w0dgtlcF+Vqx82HpJ1fYypq9kAl+7omQle2W X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2012-04/txt/msg00723.txt.bz2 > 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. =A0Yes 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 > >> >> =A0-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. =A0The abstract syntax tree provided by Clang is = an >>>> easier data structure to work with for front-end analyses of this >>>> kind. =A0Moreover, the gcc implementation of annotalysis has some issu= es >>>> 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. =A0The clang implementation has been in trunk fr= om >>>> the beginning. >>>> >>>> Hope that explains it a bit better, >>> >>> No, that it does not help at all. =A0This seems like a high level issue >>> of the problem rather than describing the reasons why GIMPLE will >>> never work correctly for your usage. =A0Maybe we can expand it for your >>> usage but we need to better understand what it is lacking. >>> >>> Thanks, >>> Andrew Pinski >>> >>> >>>> >>>> =A0-DeLesley >>>> >>>> On Thu, Apr 19, 2012 at 8:15 AM, Andrew Pinski wro= te: >>>>> 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. =A0We will not be pursuing a merge into trun= k. >>>>>> Instead, we have started implementing the same functionality in Clan= g. >>>>> >>>>> What went into making this decision? =A0I know lot of folks will almo= st >>>>> never go over to using clang since it means supporting one extra >>>>> front-end. =A0I am thinking of the embedded folks here where they can= not >>>>> 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-03= 15 --=20 DeLesley Hutchins | Software Engineer | delesley@google.com | 505-206-0315