From patchwork Mon Mar 4 17:11:24 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Martin Jambor X-Patchwork-Id: 224774 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 24F082C0326 for ; Tue, 5 Mar 2013 04:14:28 +1100 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1363022069; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Date: From:To:Subject:Message-ID:Mail-Followup-To:MIME-Version: Content-Type:Content-Disposition:User-Agent:Mailing-List: Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:Sender:Delivered-To; bh=xYjTNVrSeASs/d4LIvysBqzBPhg=; b=VxWZfBEu9tiFwzy4bYzvoJKhMaeESwrzeXB3cgANrQj+lqPTgzx43G/biLx74t OLinMWdjogD3Fspgf+6X1HQyzVAoHVi46E8/S3TPppspt1OjLIYqiipq3IfTp98V C3HLCQD4hl+udtLHMVppdf812wveMF6nxug2JWjLMlbUQ= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:Date:From:To:Subject:Message-ID:Mail-Followup-To:MIME-Version:Content-Type:Content-Disposition:User-Agent:X-IsSubscribed:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=us4YP8WH4dep7mDsv1d/JIU2K18BAOu9nSai/rtXW98FoCQaxvdE1BrelwKE+H WA+hKc8e5YAVxbhfMmFJgHEFz0ZcFksbOYwWTYl1lxf9OzPJaN2ICsnbpZw0TwTf coxdKlCuSWR9f2LIgIO1lmyk5G6F/gKZI/ZLzeJ3UUMcM=; Received: (qmail 19072 invoked by alias); 4 Mar 2013 17:12:01 -0000 Received: (qmail 18986 invoked by uid 22791); 4 Mar 2013 17:11:58 -0000 X-SWARE-Spam-Status: No, hits=-5.5 required=5.0 tests=AWL, BAYES_00, KHOP_RCVD_UNTRUST, RCVD_IN_DNSWL_HI X-Spam-Check-By: sourceware.org Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 04 Mar 2013 17:11:25 +0000 Received: from relay1.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id B42C6A4E82 for ; Mon, 4 Mar 2013 18:11:24 +0100 (CET) Date: Mon, 4 Mar 2013 18:11:24 +0100 From: Martin Jambor To: GCC Patches Subject: [PATCH] Make get_or_create_ssa_default_def consistently use the fn parameter Message-ID: <20130304171123.GA4393@virgil.suse> Mail-Followup-To: GCC Patches MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) 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 Hi, today I have noticed that get_or_create_ssa_default_def passes its struct function parameter to ssa_default_def but then happily uses a cfun-only make_ssa_name and even explicitely passes cfun to set_ssa_default_def. Fixed with the patch below. Bootstrapped and tested on x86_64-linux. Given that all current callers pass cfun as the first parameter I believe this is so low risk that I'd like to commit it to trunk even though it does not really cause any regression. However, I'm also fine with waiting for stage1. What do you think? Thanks, Martin 2013-03-04 Martin Jambor * tree-dfa.c (get_or_create_ssa_default_def): Use parameter fn in all appropriate places. Index: src/gcc/tree-dfa.c =================================================================== --- src.orig/gcc/tree-dfa.c +++ src/gcc/tree-dfa.c @@ -362,8 +362,8 @@ get_or_create_ssa_default_def (struct fu tree ddef = ssa_default_def (fn, var); if (ddef == NULL_TREE) { - ddef = make_ssa_name (var, gimple_build_nop ()); - set_ssa_default_def (cfun, var, ddef); + ddef = make_ssa_name_fn (fn, var, gimple_build_nop ()); + set_ssa_default_def (fn, var, ddef); } return ddef; }