From patchwork Mon Sep 30 10:24:56 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tristan Gingold X-Patchwork-Id: 279099 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 89DDF2C0082 for ; Mon, 30 Sep 2013 20:25:06 +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 :content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; q=dns; s= default; b=mBlwS9ejpQk6cSZH8RshR+AyQBhZrEUUHix0CzA04dD9nqaWPeGyL OVsS6tGmhH/dpGWuXJmXcV31H2JXAFBQ/J8s4zV9/HJ4FvWqs9/0uCutfu5WbTMP BQIJMSVJP1ebeZHaAp2jfn0AK/7vQt1dARujBTMy1DLSiRS2Z/Rs1c= 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 :content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=default; bh=s1MwQypHb65JpLRwOO20MJIs5QU=; b=ioy4OEUCc935NOglzsznY5gCRcch bmL0W3Idn4QyK6SGq3k8TI/10iswFzlDz3jetOpmAyKX1T8iu4ZoorlQHhpHGJVv 0REcohslafOvI98AO8z1MndHb17lD3tWEw+X3Qa0a0CVOTHLZOiuaS4H38YY8NOg DcQE4C/bHWd1Aro= Received: (qmail 23770 invoked by alias); 30 Sep 2013 10:24:59 -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 23758 invoked by uid 89); 30 Sep 2013 10:24:59 -0000 Received: from mel.act-europe.fr (HELO smtp.eu.adacore.com) (194.98.77.210) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Mon, 30 Sep 2013 10:24:59 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED, AWL, BAYES_00 autolearn=ham version=3.3.2 X-HELO: smtp.eu.adacore.com Received: from localhost (localhost [127.0.0.1]) by filtered-smtp.eu.adacore.com (Postfix) with ESMTP id 7698426683A5; Mon, 30 Sep 2013 12:24:55 +0200 (CEST) Received: from smtp.eu.adacore.com ([127.0.0.1]) by localhost (smtp.eu.adacore.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x_h7Nr2MrU1V; Mon, 30 Sep 2013 12:24:55 +0200 (CEST) Received: from ulanbator.act-europe.fr (ulanbator.act-europe.fr [10.10.1.67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.eu.adacore.com (Postfix) with ESMTPSA id 649242668251; Mon, 30 Sep 2013 12:24:55 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: [PATCH]: Fix use of __builtin_eh_pointer in EH_ELSE From: Tristan Gingold In-Reply-To: <5241DF37.4020603@redhat.com> Date: Mon, 30 Sep 2013 12:24:56 +0200 Cc: GCC Patches Message-Id: <6653B060-80E3-4186-8920-AE9870CDDA72@adacore.com> References: <5241DF37.4020603@redhat.com> To: Richard Henderson X-IsSubscribed: yes On Sep 24, 2013, at 8:51 PM, Richard Henderson wrote: > On 09/03/2013 07:08 AM, Tristan Gingold wrote: >> Hi, >> >> The field state->ehp_region wasn't updated before lowering constructs in the eh >> path of EH_ELSE. As a consequence, __builtin_eh_pointer is lowered to 0 (or >> possibly to a wrong region number) in this path. >> >> The only user of EH_ELSE looks to be trans-mem.c:lower_transaction, and the >> consequence of that is a memory leak. >> >> Furthermore, according to calls.c:flags_from_decl_or_type, the "transaction_pure" >> attribute must be set on the function type, not on the function declaration. >> Hence the change to declare __builtin_eh_pointer. >> (I don't understand the guard condition to set the attribute for it in tree.c. >> Why is 'builtin_decl_explicit_p (BUILT_IN_TM_LOAD_1)' needed in addition to >> flag_tm ?) > > Clearly these are totally unrelated and should not be in the same patch. This wasn't clear to me, as I got 'unsafe function call __builtin_eh_pointer in atomic transaction' before fixing the transaction_pure. So here is the 'transaction_pure' part. No check-host regressions on x86_64-linux-gnu. Ok for trunk ? Tristan. 2013-09-03 Tristan Gingold * tree.c (set_call_expr_flags): Reject ECF_TM_PURE. (build_common_builtin_nodes): Set "transaction_pure" attribute on __builtin_eh_pointer function type (and not on its declaration). diff --git a/gcc/tree.c b/gcc/tree.c index f0ee309..e4be24d 100644 --- a/gcc/tree.c +++ b/gcc/tree.c @@ -9817,9 +9817,11 @@ set_call_expr_flags (tree decl, int flags) if (flags & ECF_LEAF) DECL_ATTRIBUTES (decl) = tree_cons (get_identifier ("leaf"), NULL, DECL_ATTRIBUTES (decl)); - if ((flags & ECF_TM_PURE) && flag_tm) - DECL_ATTRIBUTES (decl) = tree_cons (get_identifier ("transaction_pure"), - NULL, DECL_ATTRIBUTES (decl)); + + /* The "transaction_pure" attribute must be set on the function type, not + on the declaration. */ + gcc_assert (!(flags & ECF_TM_PURE)); + /* Looping const or pure is implied by noreturn. There is currently no way to declare looping const or looping pure alone. */ gcc_assert (!(flags & ECF_LOOPING_CONST_OR_PURE) @@ -10018,8 +10020,9 @@ build_common_builtin_nodes (void) integer_type_node, NULL_TREE); ecf_flags = ECF_PURE | ECF_NOTHROW | ECF_LEAF; /* Only use TM_PURE if we we have TM language support. */ - if (builtin_decl_explicit_p (BUILT_IN_TM_LOAD_1)) - ecf_flags |= ECF_TM_PURE; + if (flag_tm && builtin_decl_explicit_p (BUILT_IN_TM_LOAD_1)) + TYPE_ATTRIBUTES (ftype) = tree_cons (get_identifier ("transaction_pure"), + NULL, TYPE_ATTRIBUTES (ftype)); local_define_builtin ("__builtin_eh_pointer", ftype, BUILT_IN_EH_POINTER, "__builtin_eh_pointer", ecf_flags);