From patchwork Fri Sep 13 15:31:23 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Jelinek X-Patchwork-Id: 274799 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]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 9845E2C0154 for ; Sat, 14 Sep 2013 01:31:39 +1000 (EST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:message-id:reply-to:mime-version :content-type; q=dns; s=default; b=Hjt8Pzgc8Fs3kylvHjOOn08J44H7Y UJbZTd/XjByiNMhhg3VxZTEps8gzihEnaeZ20axBx6mva58ZhYkDlrIbjh6fGI6N V0GKR2NqDiCV4eSsZRiMm7jwOx+qGslpPWIaoCUGdWDyae41X26LduvFWCCiZV0D D8WO+4VtCOcS2E= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:message-id:reply-to:mime-version :content-type; s=default; bh=sszz5rEzm1M8ZWqwMHUjeUBtZFw=; b=kph dysKcNMSgO+XTiQPJhrb5DS++fAj1pH20hrUt+4W0zJFIxy3rRJVgtsWcFrvc9cp sQlVs8MCZU598RNRveAeGhz2c0tRj89DnSG7gCw2biLGH6oyN3fFvxd2NWmXEMn7 XD6p0ci6HvXBLkCVgkxnJs7RJzINZCaXmDFzH9BQ= Received: (qmail 15316 invoked by alias); 13 Sep 2013 15:31:32 -0000 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 Received: (qmail 15236 invoked by uid 89); 13 Sep 2013 15:31:32 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 13 Sep 2013 15:31:32 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=AWL, BAYES_00, RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r8DFVQu1031818 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 13 Sep 2013 11:31:27 -0400 Received: from tucnak.zalov.cz (vpn1-7-200.ams2.redhat.com [10.36.7.200]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r8DFVOVu024508 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Sep 2013 11:31:26 -0400 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.14.7/8.14.7) with ESMTP id r8DFVO29003091; Fri, 13 Sep 2013 17:31:24 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.14.7/8.14.7/Submit) id r8DFVNvU002971; Fri, 13 Sep 2013 17:31:23 +0200 Date: Fri, 13 Sep 2013 17:31:23 +0200 From: Jakub Jelinek To: Martin Jambor , Jan Hubicka Cc: gcc-patches@gcc.gnu.org Subject: Recent IPA regression with internal functions Message-ID: <20130913153123.GF1817@tucnak.redhat.com> Reply-To: Jakub Jelinek MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes Hi! I've merged today gomp-4_0-branch from the trunk, but I'm seeing various regressions. The ICEs look like (e.g. on libgomp.c/simd-1.c (and other simd tests): 0xadf61a crash_signal ../../gcc/toplev.c:335 0x571a0e tree_check2(tree_node*, char const*, int, char const*, tree_code, tree_code) ../../gcc/tree.h:2667 0x8f5424 ipa_get_callee_param_type ../../gcc/ipa-prop.c:1513 0x8f5662 ipa_compute_jump_functions_for_edge ../../gcc/ipa-prop.c:1561 0x8f5c20 ipa_compute_jump_functions ../../gcc/ipa-prop.c:1649 0x8f7337 ipa_analyze_node(cgraph_node*) ../../gcc/ipa-prop.c:2169 0x10e85d0 ipcp_generate_summary ../../gcc/ipa-cp.c:3624 The problem is in ipa_get_callee_param_type: 1509 int n; 1510 tree type = (e->callee 1511 ? TREE_TYPE (e->callee->symbol.decl) 1512 : gimple_call_fntype (e->call_stmt)); 1513 tree t = TYPE_ARG_TYPES (type); e->call_stmt in this case is an internal builtin function, and builtin internal functions don't have a fntype: static inline tree gimple_call_fntype (const_gimple gs) { GIMPLE_CHECK (gs, GIMPLE_CALL); if (gimple_call_internal_p (gs)) return NULL_TREE; return gs->gimple_call.u.fntype; } The following patch fixes this. Is this ok? I don't see ever that it would be worth to try to do anything with internal calls, especially when they are all magic. 2013-09-13 Jakub Jelinek * ipa-prop.c (ipa_compute_jump_functions_for_edge): Return early for internal calls. Jakub --- gcc/ipa-prop.c.jj 2013-09-13 16:48:54.000000000 +0200 +++ gcc/ipa-prop.c 2013-09-13 17:28:28.086058903 +0200 @@ -1551,6 +1551,8 @@ ipa_compute_jump_functions_for_edge (str return; vec_safe_grow_cleared (args->jump_functions, arg_num); + if (gimple_call_internal_p (call)) + return; if (ipa_func_spec_opts_forbid_analysis_p (cs->caller)) return;