From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30512 invoked by alias); 20 Apr 2012 08:50:32 -0000 Received: (qmail 30502 invoked by uid 22791); 20 Apr 2012 08:50:30 -0000 X-SWARE-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-iy0-f175.google.com (HELO mail-iy0-f175.google.com) (209.85.210.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 20 Apr 2012 08:50:17 +0000 Received: by iaag37 with SMTP id g37so14146073iaa.20 for ; Fri, 20 Apr 2012 01:50:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.28.9 with SMTP id l9mr4109549icc.31.1334911816930; Fri, 20 Apr 2012 01:50:16 -0700 (PDT) Received: by 10.42.228.200 with HTTP; Fri, 20 Apr 2012 01:50:16 -0700 (PDT) In-Reply-To: <4F90738D.5080302@google.com> References: <4F901DEA.1060401@google.com> <4F90738D.5080302@google.com> Date: Fri, 20 Apr 2012 08:50:00 -0000 Message-ID: Subject: Re: Announce - Thread safety annotations no longer supported in GCC From: Richard Guenther To: Diego Novillo Cc: Andrew Pinski , Delesley Hutchins , gcc , Ollie Wild , Le-Chun Wu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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/msg00730.txt.bz2 On Thu, Apr 19, 2012 at 10:20 PM, Diego Novillo wrote: > On 4/19/12 4:14 PM, Andrew Pinski wrote: > >> How do you know it is a major effort? =A0Has 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? > > > The kind of analysis that Annotalysis needs cannot be catered by GIMPLE, = the > same way that LLVM's bitcode could not cater to it. =A0Both representatio= ns > are geared towards code transformations, not source code analysis. =A0It'= s not > an implementation issue, but a design one. =A0It simply does not make sen= se > for GIMPLE or LLVM's bitcode to try to be a source code analysis framewor= k. > > Annotalysis needs a high-fidelity representation of the original source > code. =A0Today, that high-fidelity representation is provided exclusively= by > Clang. > > Additionally, we are already supporting Clang as a front end to provide > syntax and semantic analysis. =A0Given that Clang provides a much more > flexible framework for static analysis, the decision was a relatively sim= ple > one. > > This is not to say that Clang provides everything needed by Annotalysis. > =A0There is some need to use dataflow information which needs to be > incorporated in Clang. =A0However, a large fraction of the support requir= ed > was already available in Clang. Our high-level AST is language specific. In case of C++ its GENERIC plus some C++ specific tree codes. There is no framework for building a CFG on top of that (not sure if you need that), but the cgraph is built over th= at representation. Of course non-optimizing ASTs will limit static analysis to TU scope, even with clang? Or does clang support a "LTO" source AST? Richard. > > Diego.