From patchwork Fri Nov 28 15:24:48 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jonathan Wakely X-Patchwork-Id: 415897 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.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 8CD6514018B for ; Sat, 29 Nov 2014 02:25:05 +1100 (AEDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; q=dns; s=default; b=cts9Tr/l28oZ0qArY aCTX7IJ7S2B7azAbUHKfXyzFFyrqx15X1v9ypzXjVeAAHLOeMh5htpHhjfJMse4X jyyUkN1CJUpjmbfUc8K0YsairCdLlIHK+KpKTr+1HDlyd6hb+730HRtLUAoSwzyf sxU+lQ4hkCap7ND6+YWDhueqyc= 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:date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=default; bh=CPY/XwA/XIgBknAiUP5lW/I lsII=; b=dcXEij/je/KimkQXDfqc50Vmg6AWRxF5nNSRws+Y9R3AhdX+vhu3fxA 4XP8yx+OC5051MIk4SRBWkhx84AYhU6SY4cGg7/qMoeUY4FEqkoq9zoLA0LnucKT rm6kP8XxOe167Kit93Px5FzAfDpvHHag6fdN3T3lD1YrgXhTAxuo= Received: (qmail 4692 invoked by alias); 28 Nov 2014 15:24:57 -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 4668 invoked by uid 89); 28 Nov 2014 15:24:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=2.9 required=5.0 tests=AWL, BAYES_00, SPF_HELO_PASS, SPF_PASS, T_RP_MATCHES_RCVD, ZIP_ATTACHED autolearn=no version=3.3.2 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; Fri, 28 Nov 2014 15:24:54 +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 (8.14.4/8.14.4) with ESMTP id sASFOp7A002845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 28 Nov 2014 10:24:51 -0500 Received: from localhost (ovpn-116-120.ams2.redhat.com [10.36.116.120]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id sASFOnle009553; Fri, 28 Nov 2014 10:24:49 -0500 Date: Fri, 28 Nov 2014 15:24:48 +0000 From: Jonathan Wakely To: libstdc++@gcc.gnu.org, gcc-patches@gcc.gnu.org Cc: Christopher Jefferson , Markus Trippelsdorf Subject: Re: [patch] New std::string implementation Message-ID: <20141128152448.GQ5191@redhat.com> References: <20141114154330.GH5191@redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20141114154330.GH5191@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) Here's the next version of the std::string rework, this time with 57.1428% more locale facets! The problem is that there are several facet types that use std::string in their public interfaces and as the parameters (or worse, as return types) of virtual functions. It's not possible to overload the functions to take either the old std::string or the new std::string because that would add virtual functions to the vtable which is an ABI change (and you can't overload on return type anyway). The facets are used deep in the guts of locales and iostreams so need to remain compatible. My solution is to add a second version of each affected facet, with one version using the old ABI and one using the new, but with otherwise the same behaviour. When a piece of code says std::use_facet>(someLocale) they get a reference to the locale's std::collate facet with the same ABI as is in effect at the call site. The difficult part is that users can replace a facet to customise behaviour, so if they replace the old ABI version of std::collate I need to also replace the new ABI version of the same facet, using a shim that has the same behaviour as the user-defined facet (which is achieved by the shim just forwarding to the user's facet, and converting between std::string representations). I've also had to add a new virtual function to std::error_category so you can call error_category::message() (which returns a std::string) in the context of either ABI. Adding the virtual grows the size of the vtable in a type that's been exported from libstdc++.so since 4.4.0 so I moved std::error_category to src/c++11/compatibility-c++0x.cc and added a new std::_V2::error_category in the same inline namespace used for a similar switcheroo on std::condition_variable_any With these changes the entire libstdc++ testsuite passes when using either ABI, confirming that the library still exports everything needed for existing code (compiled with GCC <5) to keep working, but also contains everything for new code (GCC 5+) to work. Tested x86_64-linux with: --target_board=unix\{-m32,\}\{,-D_GLIBCXX_USE_CXX11_ABI=0\} Also tested on powerpc64-linux (where this patch doesn't actually bootstrap due to PR 63573, there's a patch in the PR that's needed) and i686-linux. The Python pretty printers for std::string fail with the new ABI. I'm not sure why, I think GDB is failing to distinguish between the two types of std::string. That will only require changes to the python code though.