From patchwork Thu Mar 3 14:33:32 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alan Modra X-Patchwork-Id: 85290 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id D8A6B1007D6 for ; Fri, 4 Mar 2011 01:33:50 +1100 (EST) Received: (qmail 21892 invoked by alias); 3 Mar 2011 14:33:49 -0000 Received: (qmail 21880 invoked by uid 22791); 3 Mar 2011 14:33:47 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL, BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW, T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: sourceware.org Received: from mail-pw0-f47.google.com (HELO mail-pw0-f47.google.com) (209.85.160.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 03 Mar 2011 14:33:40 +0000 Received: by pwj9 with SMTP id 9so255050pwj.20 for ; Thu, 03 Mar 2011 06:33:39 -0800 (PST) Received: by 10.142.142.16 with SMTP id p16mr859895wfd.248.1299162817842; Thu, 03 Mar 2011 06:33:37 -0800 (PST) Received: from bubble.grove.modra.org ([115.187.252.19]) by mx.google.com with ESMTPS id m10sm1514335wfl.23.2011.03.03.06.33.36 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 03 Mar 2011 06:33:37 -0800 (PST) Received: by bubble.grove.modra.org (Postfix, from userid 1000) id 59924170C1FA; Fri, 4 Mar 2011 01:03:32 +1030 (CST) Date: Fri, 4 Mar 2011 01:03:32 +1030 From: Alan Modra To: gcc-patches@gcc.gnu.org Subject: build_function_call and TREE_ADDRESSABLE Message-ID: <20110303143332.GJ13094@bubble.grove.modra.org> Mail-Followup-To: gcc-patches@gcc.gnu.org MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org TREE_ADDRESSABLE comment says "In a FUNCTION_DECL, nonzero means its address is needed". However, as I point out in http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01525.html, this flag gets set when making normal calls. It wasn't always like this. gcc-4.0 was careful to not set TREE_ADDRESSABLE on FUNCTION_DECLs in build_function_call, a feature lost in revision 100984. I'd like to have that feature back for the above patch. Bootstrapped and regression tested powerpc-linux. OK for 4.6? * c-typeck.c (build_function_call_vec): Avoid setting TREE_ADDRESSABLE on normal function calls. Index: gcc/c-typeck.c =================================================================== --- gcc/c-typeck.c (revision 170607) +++ gcc/c-typeck.c (working copy) @@ -2715,7 +2715,20 @@ build_function_call_vec (location_t loc, fundecl = function; } if (TREE_CODE (TREE_TYPE (function)) == FUNCTION_TYPE) - function = function_to_pointer_conversion (loc, function); + { + if (fundecl) + { + /* Don't set TREE_ADDRESSABLE for the implicit function + pointer conversion in a function call. This allows + TREE_ADDRESSABLE to be used to detect explicit function + address operations. */ + bool addressable = TREE_ADDRESSABLE (fundecl); + function = function_to_pointer_conversion (loc, function); + TREE_ADDRESSABLE (fundecl) = addressable; + } + else + function = function_to_pointer_conversion (loc, function); + } /* For Objective-C, convert any calls via a cast to OBJC_TYPE_REF expressions, like those used for ObjC messenger dispatches. */