From patchwork Sat Dec 8 18:33:51 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: David Edelsohn X-Patchwork-Id: 204675 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 6FF982C0209 for ; Sun, 9 Dec 2012 05:34:05 +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=1355596446; h=Comment: DomainKey-Signature:Received:Received:Received:Received: MIME-Version:Received:Received:In-Reply-To:References:Date: Message-ID:Subject:From:To:Cc:Content-Type:Mailing-List: Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:Sender:Delivered-To; bh=ybAHOKb2jvNDM6UPFsDM0dZIRBI=; b=jnHnZiNw5y5FZGWG2OOEofRHmrwreU8hZ5D1VsocflKfsnn02l32Hk9SsBpdIG oPZ60BZ3cvITQGrp0MLN93FssdmCALs7b64asMOLi4a8lH5YdJsId7MlvRzfaAP2 +L7qf+0emXAzkk2E8CUBp4AQAvBZ9Hev1q4/TtZnF1t6U= 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:MIME-Version:Received:Received:In-Reply-To:References:Date:Message-ID:Subject:From:To:Cc:Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=Jo4EkrbD5tuTOwJgpTw0mvCrNuyOJdw9Ls1uAaL3MSpiwY2GmSrAJS0rmJ+WR0 smvHhxXQD3P4wh4i3uHQXhDUL3fBdLwKFIad6xvfR5/W5NDdPrHykjQEpM9Z56GN J9e6Bmq+Am6aOoW04F5wHT5BwK1RYvQfkCudfy/l1PabU=; Received: (qmail 25052 invoked by alias); 8 Dec 2012 18:33:58 -0000 Received: (qmail 25043 invoked by uid 22791); 8 Dec 2012 18:33:57 -0000 X-SWARE-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL, BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, KAM_STOCKGEN, KHOP_RCVD_TRUST, KHOP_THREADED, RCVD_IN_DNSWL_LOW, RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-vb0-f47.google.com (HELO mail-vb0-f47.google.com) (209.85.212.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 08 Dec 2012 18:33:52 +0000 Received: by mail-vb0-f47.google.com with SMTP id e21so1425958vbm.20 for ; Sat, 08 Dec 2012 10:33:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.140.143 with SMTP id i15mr6034485vcu.15.1354991631895; Sat, 08 Dec 2012 10:33:51 -0800 (PST) Received: by 10.58.235.232 with HTTP; Sat, 8 Dec 2012 10:33:51 -0800 (PST) In-Reply-To: References: Date: Sat, 8 Dec 2012 13:33:51 -0500 Message-ID: Subject: [RFC] Remove TLS symbols from section anchor blocks From: David Edelsohn To: Richard Sandiford Cc: GCC Patches 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 [Sorry, I forgot to copy GCC Patches before] Some of the libgomp testcases fail on AIX when using native TLS because variables annotated with #pragma omp threadprivate(thr) sometimes are placed in section anchor blocks. Variables declared with "__thread" create decls with the correct TLS model from the beginning, but OpenMP sometimes creates a decl with TLS_MODEL_NONE and later tries to make the decl again. make_decl_rtl() is called again and it calls ENCODE_SECTION_INFO and then change_symbol_block(). However ENCODE_SECTION_INFO explicitly preserves SYMBOL_FLAG_HAS_BLOCK_INFO and change_symbol_block() place the symbol in a different block but never re-assesses if the new attributes of the symbol make it in appropriate for section anchor blocks. The following patch adds an ENCODE_SECTION_INFO hook for AIX that removes the SYMBOL_FLAG_HAS_BLOCK_INFO flag if the symbol is DECL_THREAD_LOCAL_P. This prevents the symbol from being emitted in a section anchor block and it correctly is emitted in its own section; it does not remove it from the section anchor blocks data structures. This fixes some of the libgomp failures. Is this a reasonable approach? Or should change_symbol_block re-test use_blocks_for_symbol_p()? Thanks, David Index: rs6000.c =================================================================== --- rs6000.c (revision 194278) +++ rs6000.c (working copy) @@ -25886,6 +25886,29 @@ ? "\t.long _section_.text\n" : "\t.llong _section_.text\n", asm_out_file); } + +static void +rs6000_xcoff_encode_section_info (tree decl, rtx rtl, int first) +{ + rtx symbol; + int flags; + + default_encode_section_info (decl, rtl, first); + + /* Careful not to prod global register variables. */ + if (!MEM_P (rtl)) + return; + symbol = XEXP (rtl, 0); + if (GET_CODE (symbol) != SYMBOL_REF) + return; + + flags = SYMBOL_REF_FLAGS (symbol); + + if (TREE_CODE (decl) == VAR_DECL && DECL_THREAD_LOCAL_P (decl)) + flags &= ~SYMBOL_FLAG_HAS_BLOCK_INFO; + + SYMBOL_REF_FLAGS (symbol) = flags; +} #endif /* TARGET_XCOFF */ /* Compute a (partial) cost for rtx X. Return true if the complete