From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 84026 invoked by alias); 1 Sep 2015 15:42:29 -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 83974 invoked by uid 89); 1 Sep 2015 15:42:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mail-wi0-f182.google.com Received: from mail-wi0-f182.google.com (HELO mail-wi0-f182.google.com) (209.85.212.182) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 01 Sep 2015 15:42:26 +0000 Received: by wicfx3 with SMTP id fx3so17122244wic.0 for ; Tue, 01 Sep 2015 08:42:24 -0700 (PDT) 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:from:date :message-id:subject:to:cc:content-type; bh=dkLY4zhPG8apSTQfpgyc/BbhEiJE3qc7lIj/AOET/94=; b=Yx4FL14335LbxiBZmy9bsyAVyJtO0go+6pNrq/4L8k+Mw5LOEiMpHlv5sK1ljBWxyU s7Qzgz/KAl42DS/+kyyP8DeIK6IqUr/Sgcl/VP4rhN2iKS9m2sqZCC0hVoBhUYszwl8h XK0Qag7itNsug819djUclR0IQH6cebg9/cOE+iqjFnUoIgYzhwDmz4hLJC4XU1Ac2tRF oudYlEIEqbm8NrvJtmd87HEjZfqfFTgI7Kft6J0WTuEwRfII3Cfm9Ldh9Q6SqlnX0SqI Va68cy0hI8yGsFsqYx+2zoRjH3h/xtBWPzGaHjzR5jCtG9TiSUXAsss7jowTa8HI9cbq RV9w== X-Gm-Message-State: ALoCoQncSZTiT4LJuUHURARiSlF3vXU67QiAuCDyNl/lcsdxekwNp0fxw5+1dzfSXMNmKFtmMcZW X-Received: by 10.194.205.37 with SMTP id ld5mr37496820wjc.14.1441122143935; Tue, 01 Sep 2015 08:42:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.64.193 with HTTP; Tue, 1 Sep 2015 08:42:04 -0700 (PDT) In-Reply-To: <20150901150847.GH2631@redhat.com> References: <20150901142713.GG2631@redhat.com> <20150901150847.GH2631@redhat.com> From: Dmitry Vyukov Date: Tue, 01 Sep 2015 15:42:00 -0000 Message-ID: Subject: Re: [Patch, libstdc++] Fix data races in basic_string implementation To: Jonathan Wakely Cc: GCC Patches , libstdc++@gcc.gnu.org, Alexander Potapenko , Kostya Serebryany , Torvald Riegel Content-Type: multipart/mixed; boundary=047d7bb70c58780258051eb1658a X-IsSubscribed: yes X-SW-Source: 2015-09/txt/msg00080.txt.bz2 --047d7bb70c58780258051eb1658a Content-Type: text/plain; charset=UTF-8 Content-length: 1405 On Tue, Sep 1, 2015 at 5:08 PM, Jonathan Wakely wrote: > On 01/09/15 16:56 +0200, Dmitry Vyukov wrote: >> >> I don't understand how a new gcc may not support __atomic builtins on >> ints. How it is even possible? That's a portable API provided by >> recent gcc's... > > > The built-in function is always defined, but it might expand to a call > to an external function in libatomic, and it would be a regression for > code using std::string to start requiring libatomic (although maybe it > would be necessary if it's the only way to make the code correct). > > I don't know if there are any targets that define __GTHREADS and also > don't support __atomic_load(int*, ...) without libatomic. If such > targets exist then adding a new configure check that only depends on > __atomic_load(int*, ...) would mean we keep supporting those targets. > > Another option would be to simply do: > > bool > _M_is_shared() const _GLIBCXX_NOEXCEPT > #if defined(__GTHREADS) > + { return __atomic_load(&this->_M_refcount, __ATOMIC_ACQUIRE) > 0; } > +#else > { return this->_M_refcount > 0; } > +#endif > > and see if anyone complains! I like this option! If a platform uses multithreading and has non-inlined atomic loads, then the way to fix this is to provide inlined atomic loads rather than to fix all call sites. Attaching new patch. Please take another look. --047d7bb70c58780258051eb1658a Content-Type: text/plain; charset=US-ASCII; name="patch.diff" Content-Disposition: attachment; filename="patch.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ie1iw0sg0 Content-length: 1965 SW5kZXg6IGluY2x1ZGUvYml0cy9iYXNpY19zdHJpbmcuaAo9PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09Ci0tLSBpbmNsdWRlL2JpdHMvYmFzaWNfc3RyaW5nLmgJ KHJldmlzaW9uIDIyNzM2MykKKysrIGluY2x1ZGUvYml0cy9iYXNpY19zdHJp bmcuaAkod29ya2luZyBjb3B5KQpAQCAtMjYwMSwxMSArMjYwMSwzMiBAQAog CiAgICAgICAgIGJvb2wKIAlfTV9pc19sZWFrZWQoKSBjb25zdCBfR0xJQkNY WF9OT0VYQ0VQVAotICAgICAgICB7IHJldHVybiB0aGlzLT5fTV9yZWZjb3Vu dCA8IDA7IH0KKyAgICAgICAgeworI2lmIGRlZmluZWQoX19HVEhSRUFEUykK KyAgICAgICAgICAvLyBfTV9yZWZjb3VudCBpcyBtdXRhdGVkIGNvbmN1cnJl bnRseSBieSBfTV9yZWZjb3B5L19NX2Rpc3Bvc2UsCisgICAgICAgICAgLy8g c28gd2UgbmVlZCB0byB1c2UgYW4gYXRvbWljIGxvYWQuIEhvd2V2ZXIsIF9N X2lzX2xlYWtlZAorICAgICAgICAgIC8vIHByZWRpY2F0ZSBkb2VzIG5vdCBj aGFuZ2UgY29uY3VycmVudGx5IChpLmUuIHRoZSBzdHJpbmcgaXMgZWl0aGVy CisgICAgICAgICAgLy8gbGVha2VkIG9yIG5vdCksIHNvIGEgcmVsYXhlZCBs b2FkIGlzIGVub3VnaC4KKyAgICAgICAgICByZXR1cm4gX19hdG9taWNfbG9h ZF9uKCZ0aGlzLT5fTV9yZWZjb3VudCwgX19BVE9NSUNfUkVMQVhFRCkgPCAw OworI2Vsc2UKKyAgICAgICAgICByZXR1cm4gdGhpcy0+X01fcmVmY291bnQg PCAwOworI2VuZGlmCisgICAgICAgIH0KIAogICAgICAgICBib29sCiAJX01f aXNfc2hhcmVkKCkgY29uc3QgX0dMSUJDWFhfTk9FWENFUFQKLSAgICAgICAg eyByZXR1cm4gdGhpcy0+X01fcmVmY291bnQgPiAwOyB9CisJeworI2lmIGRl ZmluZWQoX19HVEhSRUFEUykKKyAgICAgICAgICAvLyBfTV9yZWZjb3VudCBp cyBtdXRhdGVkIGNvbmN1cnJlbnRseSBieSBfTV9yZWZjb3B5L19NX2Rpc3Bv c2UsCisgICAgICAgICAgLy8gc28gd2UgbmVlZCB0byB1c2UgYW4gYXRvbWlj IGxvYWQuIEFub3RoZXIgdGhyZWFkIGNhbiBkcm9wIGxhc3QKKyAgICAgICAg ICAvLyBidXQgb25lIHJlZmVyZW5jZSBjb25jdXJyZW50bHkgd2l0aCB0aGlz IGNoZWNrLCBzbyB3ZSBuZWVkIHRoaXMKKyAgICAgICAgICAvLyBsb2FkIHRv IGJlIGFjcXVpcmUgdG8gc3luY2hyb25pemUgd2l0aCByZWxlYXNlIGZldGNo X2FuZF9hZGQgaW4KKyAgICAgICAgICAvLyBfTV9kaXNwb3NlLgorICAgICAg ICAgIHJldHVybiBfX2F0b21pY19sb2FkX24oJnRoaXMtPl9NX3JlZmNvdW50 LCBfX0FUT01JQ19BQ1FVSVJFKSA+IDA7CisjZWxzZQorICAgICAgICAgIHJl dHVybiB0aGlzLT5fTV9yZWZjb3VudCA+IDA7CisjZW5kaWYKKyAgICAgICAg fQogCiAgICAgICAgIHZvaWQKIAlfTV9zZXRfbGVha2VkKCkgX0dMSUJDWFhf Tk9FWENFUFQK --047d7bb70c58780258051eb1658a--