From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 119392 invoked by alias); 16 Jan 2016 22:58: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 119373 invoked by uid 89); 16 Jan 2016 22:58:16 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=20160107, transaction, friend X-Spam-User: qpsmtpd, 2 recipients X-HELO: mail-qg0-f51.google.com Received: from mail-qg0-f51.google.com (HELO mail-qg0-f51.google.com) (209.85.192.51) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Sat, 16 Jan 2016 22:58:15 +0000 Received: by mail-qg0-f51.google.com with SMTP id e32so445778873qgf.3; Sat, 16 Jan 2016 14:58:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=AFtRPgmxMYa3+1eQ7c2Ar3oXyx6lHrqkeVwKwZ4ZOVo=; b=XJr6zWtI2geI7CycaE93BOwGAABQ0lBytHVVMxUHpwYPM2S4b1a6MB29Mcb9SetCSq Dwsg6Jz6NpDqU9pmUc65N7mah4scpDrlcpVr9Mf//jRac/YMEivKsSFcnWmnCPeOE8tN aTjO7qWeUpsvbYj3kJY+B1EdfQGqSt82lb8bMy6V/7XT/dtJcD0JLbGLR9gBuuPmDnu/ XCgUqC8AOaSguLwBN/4SJKlDZ9Z28I2wI3lUcvClj6vfa1JClI6A9+pAXjsR8I4+yOcA yx0Sj8ko8gWuO4WZe5la4TLhwnsiMn59bxHEInx+pMNWkXqT49pcj6ZvnREXezTAYuL1 shTA== X-Gm-Message-State: ALoCoQnGOB9hy1CpDy7b191oIySXTsQyIjwNfDKRhnJ5w28me7gc8TeV8IgGyv5fxWAEDm4P3jX4S8IACQN++yWH5BSwOZnaqA== MIME-Version: 1.0 X-Received: by 10.140.44.38 with SMTP id f35mr22519577qga.49.1452985093152; Sat, 16 Jan 2016 14:58:13 -0800 (PST) Received: by 10.55.215.6 with HTTP; Sat, 16 Jan 2016 14:58:13 -0800 (PST) In-Reply-To: <1452185238.26597.230.camel@localhost.localdomain> References: <1452185238.26597.230.camel@localhost.localdomain> Date: Sat, 16 Jan 2016 22:58:00 -0000 Message-ID: Subject: Re: [PATCH v2] libstdc++: Make certain exceptions transaction_safe. From: "H.J. Lu" To: Torvald Riegel Cc: "libstdc++" , GCC Patches , Jonathan Wakely , Jason Merrill Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2016-01/txt/msg01205.txt.bz2 On Thu, Jan 7, 2016 at 8:47 AM, Torvald Riegel wrote: > The attached patch makes some exceptions transaction-safe, as require by > the Transactional Memory TS. I believe I addressed all feedback for the > previous version of this patch (in particular, there are now more safety > checks for preconditions for this implementation (eg, that the new > allocator is used), all exceptions declared by the TM TS are now > supported (with the exception of tx_exception -- should I add that in a > follow-up patch?), and there is a test for the new functionality (as > part of libitm's testsuite)). > > There are two things that complicate such support. First, it seems > better to not rely on -fgnu-tm of libstdc++ code for now (or at least we > tried to avoid this so far). Therefore, the transactional clones in > this patch are all manually instrumented (ie, the functions are C > functions with names matching the mangled names of the respective C++ > functions, and the _ZGTt prefix signaling that they are txnal clones). > > Second, exceptions still use a COW string internally, which cannot be > made transaction-safe with just compiler support because of the > reference counting implementation inside of COW strings, which uses > atomics. One would need something custom for that nonetheless. > > Thus, the patch adds txnal clones as required. They are new exported > symbols, but not visible to nontransactional code. The only changes to > headers is transaction_safe[_dynamic] annotations where required by the > TS, and a few friend declarations. The annotations are only enabled if > a user compiles with -fgnu-tm. IOW, the changes are pretty much > invisible when not using the TM TS. > > There are also commented-out calls to _ITM_setAssociatedException in the > code, which exist to show how we plan to support transaction > cancellation through exceptions (which needs some more libitm support > and bugfixes on the compiler side). > > Tested on x86_64-linux and x86-linux. > > OK? > > 2016-01-07 Torvald Riegel > > * include/bits/basic_string.h (basic_string): Declare friends. > * include/bits/c++config (_GLIBCXX_TXN_SAFE, > _GLIBCXX_TXN_SAFE_DYN, _GLIBCXX_USE_ALLOCATOR_NEW): New. > * include/std/stdexcept (logic_error, domain_error, invalid_argument, > length_error, out_of_range, runtime_error, range_error, > underflow_error, overflow_error): Declare members as transaction-safe. > (logic_error, runtime_error): Declare friend functions. > * libsupc++/exception (exception, bad_exception): Declare members as > transaction-safe. > * src/c++11/cow-stdexcept.cc: Define transactional clones for the > transaction-safe members of exceptions and helper functions. > * libsupc++/eh_exception.cc: Adjust and define transactional clones. > * config/abi/pre/gnu.ver (GLIBCXX_3.4.22) Add transactional clones. > (CXXABI_1.3.10): New. > * acinclude.m4 (GLIBCXX_CHECK_SIZE_T_MANGLING): New. > (GLIBCXX_ENABLE_ALLOCATOR): Set ENABLE_ALLOCATOR_NEW. > * configure.ac: Call GLIBCXX_CHECK_SIZE_T_MANGLING. > * include/Makefile.am: Write ENABLE_ALLOCATOR_NEW to c++config.h. > * include/Makefile.in: Regenerate. > * config.h.in: Regenerate. > * configure: Regenerate. > Don't you need to update baseline_symbols.txt? -- H.J.