From patchwork Wed Mar 13 19:32:24 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jason Merrill X-Patchwork-Id: 227338 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 C95822C008D for ; Thu, 14 Mar 2013 06:32:43 +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=1363807965; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:Sender:Delivered-To; bh=Z70GTxN 5GCDzDXZeJHx/P1nEvPQ=; b=btshjaVyiYC8nkzY1aDRjm7TQ70+mvpNkJrre0D n4j3Oe2Ab/Hwnxf31guFu738iFBbj7WrhpMVnns8kV+Q82BZ135LWWKItYMiwpUM s4auVuoNDpWIKFVGYULmKBRcFulOfQ4Ytu+VqfZC5AdYk/eDOptZrkalgLsoVlT+ AQiU= 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:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=oXMCTM1Q1qGjeuJCShKyLs2KJSlEWhKGEMnzobqs/nphpz1QuxKFc27uOPDYnu 3iJ4E+eXdBjqz54Gm+EzFsauASpRuwGw+2uMamdJn7eqV8xsWXIKs2/7WrrbSoIS e32SLSaX59Yjk9NkADStyi1FKG923r/E9rtzpGQ6KeKkI=; Received: (qmail 29336 invoked by alias); 13 Mar 2013 19:32:35 -0000 Received: (qmail 29320 invoked by uid 22791); 13 Mar 2013 19:32:33 -0000 X-SWARE-Spam-Status: No, hits=-7.5 required=5.0 tests=AWL, BAYES_00, KHOP_RCVD_UNTRUST, KHOP_SPAMHAUS_DROP, RCVD_IN_DNSWL_HI, RCVD_IN_HOSTKARMA_W, RP_MATCHES_RCVD, SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 13 Mar 2013 19:32:27 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r2DJWQ81012738 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 13 Mar 2013 15:32:26 -0400 Received: from [10.3.113.32] (ovpn-113-32.phx2.redhat.com [10.3.113.32]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r2DJWPUD005574; Wed, 13 Mar 2013 15:32:25 -0400 Message-ID: <5140D448.2000601@redhat.com> Date: Wed, 13 Mar 2013 15:32:24 -0400 From: Jason Merrill User-Agent: Mozilla/5.0 (X11; Linux i686; rv:21.0) Gecko/20100101 Thunderbird/21.0a2 MIME-Version: 1.0 To: gcc-patches List , Jakub Jelinek CC: John David Anglin Subject: C++ PATCH for c++/56346 (thread_local3.C link error on targets without __dso_handle) 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 We can't pass the address of __dso_handle to __cxa_thread_atexit if the target doesn't provide that symbol in the crt files. Fixed by passing NULL if the target doesn't use __cxa_atexit. Tested x86_64-pc-linux-gnu and hppa2.0w-hp-hpux11.11. This fixes broken new functionality on a secondary target; is it OK for 4.8.0 or should it wait for 4.8.1? commit 145dab2e1e46ac025414e1a225e29caa2c3b41c1 Author: Jason Merrill Date: Mon Mar 11 12:31:16 2013 -0400 PR c++/56346 * decl.c (register_dtor_fn): Pass null to __cxa_thread_atexit dso_handle parm on targets without __cxa_atexit. diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c index 150e866..92114ff 100644 --- a/gcc/cp/decl.c +++ b/gcc/cp/decl.c @@ -6758,10 +6758,9 @@ register_dtor_fn (tree decl) "__aeabi_atexit"), and DECL is a class object, we can just pass the destructor to "__cxa_atexit"; we don't have to build a temporary function to do the cleanup. */ - ob_parm = (DECL_THREAD_LOCAL_P (decl) - || (flag_use_cxa_atexit - && !targetm.cxx.use_atexit_for_cxa_atexit ())); - dso_parm = ob_parm; + dso_parm = (flag_use_cxa_atexit + && !targetm.cxx.use_atexit_for_cxa_atexit ()); + ob_parm = (DECL_THREAD_LOCAL_P (decl) || dso_parm); use_dtor = ob_parm && CLASS_TYPE_P (type); if (use_dtor) { @@ -6825,7 +6824,7 @@ register_dtor_fn (tree decl) before passing it in, to avoid spurious errors. */ addr = build_nop (ptr_type_node, addr); } - else if (ob_parm) + else /* Since the cleanup functions we build ignore the address they're given, there's no reason to pass the actual address in, and, in general, it's cheaper to pass NULL than any @@ -6835,6 +6834,10 @@ register_dtor_fn (tree decl) if (dso_parm) arg2 = cp_build_addr_expr (get_dso_handle_node (), tf_warning_or_error); + else if (ob_parm) + /* Just pass NULL to the dso handle parm if we don't actually + have a DSO handle on this target. */ + arg2 = null_pointer_node; else arg2 = NULL_TREE;