From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6075 invoked by alias); 13 May 2010 21:20:36 -0000 Received: (qmail 6062 invoked by uid 22791); 13 May 2010 21:20:35 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (74.125.121.35) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 13 May 2010 21:20:31 +0000 Received: from hpaq11.eem.corp.google.com (hpaq11.eem.corp.google.com [172.25.149.11]) by smtp-out.google.com with ESMTP id o4DLKSZH001548 for ; Thu, 13 May 2010 14:20:28 -0700 Received: from ywh39 (ywh39.prod.google.com [10.192.8.39]) by hpaq11.eem.corp.google.com with ESMTP id o4DLKQY9026796 for ; Thu, 13 May 2010 14:20:27 -0700 Received: by ywh39 with SMTP id 39so968956ywh.21 for ; Thu, 13 May 2010 14:20:26 -0700 (PDT) Received: by 10.150.63.21 with SMTP id l21mr991128yba.138.1273785625765; Thu, 13 May 2010 14:20:25 -0700 (PDT) Received: from dhcp-172-29-42-133.tor.corp.google.com ([204.50.149.209]) by mx.google.com with ESMTPS id u2sm12127711ybe.8.2010.05.13.14.20.23 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 13 May 2010 14:20:23 -0700 (PDT) Message-ID: <4BEC6D16.80009@google.com> Date: Thu, 13 May 2010 21:20:00 -0000 From: Diego Novillo User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: Kevin Williams CC: gcc@gcc.gnu.org Subject: Re: CLI-FE merge 4.3 to 4.5 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-System-Of-Record: true 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: 2010-05/txt/msg00240.txt.bz2 On 5/10/10 10:31 , Kevin Williams wrote: > 1. What is the correct behaviour for a FE in terms of setting the > global variables cfun and current_function_declaration? They should be set to the current function being parsed. These will be set to NULL when the compiler is working in IPA mode. > 2. It seems that the new api for set_cfun has some side effects on > optimization flags? is this correct? Yes, but only when function-specific optimizations are used. > 3. How should DECL_FUNCTION_SPECIFIC_ > OPTIMIZATION be controled, should the front end be setting these per > function? (I am looking to avoid IPA passes for now) Function-specific optimizations are set an attribute, the FE does not really need to do anything about them (other than making sure they are preserved. Diego.