From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 55104 invoked by alias); 16 Jan 2016 13:51:17 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 55081 invoked by uid 89); 16 Jan 2016 13:51:16 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy= X-Spam-User: qpsmtpd, 2 recipients X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Sat, 16 Jan 2016 13:51:12 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 6314414A82; Sat, 16 Jan 2016 13:51:11 +0000 (UTC) Received: from localhost (ovpn-116-32.ams2.redhat.com [10.36.116.32]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u0GDpABj008592; Sat, 16 Jan 2016 08:51:10 -0500 Date: Sat, 16 Jan 2016 13:51:00 -0000 From: Jonathan Wakely To: Jakub Jelinek Cc: David Edelsohn , Torvald Riegel , GCC Patches , "libstdc++@gcc.gnu.org" , Jason Merrill Subject: Re: [PATCH v2] libstdc++: Make certain exceptions transaction_safe. Message-ID: <20160116135109.GP15084@redhat.com> References: <20160116124323.GM15084@redhat.com> <20160116133521.GN3017@tucnak.redhat.com> <20160116134140.GO15084@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20160116134140.GO15084@redhat.com> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.5.24 (2015-08-30) X-SW-Source: 2016-01/txt/msg01192.txt.bz2 On 16/01/16 13:41 +0000, Jonathan Wakely wrote: >On 16/01/16 14:35 +0100, Jakub Jelinek wrote: >>On Sat, Jan 16, 2016 at 07:47:33AM -0500, David Edelsohn wrote: >>>stage1 libstdc++ builds just fine. the problem is stage2 configure >>>fails due to missing ITM_xxx symbols when configure tries to compile >>>and run conftest programs. >> >>On x86_64-linux, the _ITM_xxx symbols are undef weak ones and thus it is >>fine to load libstdc++ without libitm and libstdc++ doesn't depend on >>libitm. >> >>So, is AIX defining __GXX_WEAK__ or not? Perhaps some other macro or >>configure check needs to be used to determine if undefined weak symbols >>work the way libstdc++ needs them to. >> >>#if __GXX_WEAK__ >>// Declare all libitm symbols we rely on, but make them weak so that we do >>// not depend on libitm. >>extern void* _ZGTtnaX (size_t sz) __attribute__((weak)); >>extern void _ZGTtdlPv (void* ptr) __attribute__((weak)); >>extern uint8_t _ITM_RU1(const uint8_t *p) >> ITM_REGPARM __attribute__((weak)); >>extern uint32_t _ITM_RU4(const uint32_t *p) >> ITM_REGPARM __attribute__((weak)); >>extern uint64_t _ITM_RU8(const uint64_t *p) >> ITM_REGPARM __attribute__((weak)); >>extern void _ITM_memcpyRtWn(void *, const void *, size_t) >> ITM_REGPARM __attribute__((weak)); >>extern void _ITM_memcpyRnWt(void *, const void *, size_t) >> ITM_REGPARM __attribute__((weak)); >>extern void _ITM_addUserCommitAction(void (*)(void *), uint64_t, void *) >> ITM_REGPARM __attribute__((weak)); >> >>#else >>// If there is no support for weak symbols, create dummies. The exceptions >>// will not be declared transaction_safe in this case. >>void* _ZGTtnaX (size_t) { return NULL; } >>void _ZGTtdlPv (void*) { } >>uint8_t _ITM_RU1(const uint8_t *) { return 0; } >>uint32_t _ITM_RU4(const uint32_t *) { return 0; } >>uint64_t _ITM_RU8(const uint64_t *) { return 0; } >>void _ITM_memcpyRtWn(void *, const void *, size_t) { } >>void _ITM_memcpyRnWt(void *, const void *, size_t) { } >>void _ITM_addUserCommitAction(void (*)(void *), uint64_t, void *) { }; >>#endif > >I think it's better to just drop that whole section of the file if TM >isn't supported, as this patch does. > >Bootstraps OK on AIX, still testing on GNU/Linux. Doh, it causes libitm.c++/libstdc++-safeexc.C to FAIL, because TM isn't enabled when building libstdc++ ... that's the whole point of the complicated preprocessor conditions!