From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Paul E. McKenney via llvm-dev" Subject: Re: [isocpp-parallel] Proposal for new memory_order_consume definition Date: Sat, 27 Feb 2016 15:10:33 -0800 Message-ID: <20160227231033.GW3522@linux.vnet.ibm.com> References: <20160218011033.GA1505@linux.vnet.ibm.com> <20160220021516.4898897.32908.5212@gmail.com> <20160220195318.GF3522@linux.vnet.ibm.com> <20160227170615.GU3522@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: llvm-dev-bounces@lists.llvm.org Sender: "llvm-dev" To: Linus Torvalds Cc: linux-arch@vger.kernel.org, gcc@gcc.gnu.org, parallel@lists.isocpp.org, llvm-dev@lists.llvm.org, will.deacon@arm.com, linux-kernel@vger.kernel.org, dhowells@redhat.com, peterz@infradead.org, Ramana.Radhakrishnan@arm.com, Luc Maranget , akpm@linux-foundation.org, Jade Alglave , mingo@kernel.org List-Id: linux-arch.vger.kernel.org T24gU2F0LCBGZWIgMjcsIDIwMTYgYXQgMTE6MTY6NTFBTSAtMDgwMCwgTGludXMgVG9ydmFsZHMg d3JvdGU6Cj4gT24gRmViIDI3LCAyMDE2IDA5OjA2LCAiUGF1bCBFLiBNY0tlbm5leSIgPHBhdWxt Y2tAbGludXgudm5ldC5pYm0uY29tPgo+IHdyb3RlOgo+ID4KPiA+Cj4gPiBCdXQgd2UgZG8gYWxy ZWFkeSBoYXZlIHNvbWV0aGluZyB2ZXJ5IHNpbWlsYXIgd2l0aCBzaWduZWQgaW50ZWdlcgo+ID4g b3ZlcmZsb3cuICBJZiB0aGUgY29tcGlsZXIgY2FuIHNlZSBhIHdheSB0byBnZW5lcmF0ZSBmYXN0 ZXIgY29kZSB0aGF0Cj4gPiBkb2VzIG5vdCBoYW5kbGUgdGhlIG92ZXJmbG93IGNhc2UsIHRoZW4g dGhlIHNlbWFudGljcyBzdWRkZW5seSBjaGFuZ2UKPiA+IGZyb20gdHdvcy1jb21wbGVtZW50IGFy aXRobWV0aWMgdG8gc29tZXRoaW5nIHZlcnkgc3RyYW5nZS4gIFRoZSBzdGFuZGFyZAo+ID4gZG9l cyBub3Qgc3BlY2lmeSBhbGwgdGhlIHdheXMgdGhhdCB0aGUgaW1wbGVtZW50YXRpb24gbWlnaHQg ZGVkdWNlIHRoYXQKPiA+IGZhc3RlciBjb2RlIGNhbiBiZSBnZW5lcmF0ZWQgYnkgaWdub3Jpbmcg dGhlIG92ZXJmbG93IGNhc2UsIGl0IGluc3RlYWQKPiA+IHNpbXBseSBzYXlzIHRoYXQgc2lnbmVk IGludGVnZXIgb3ZlcmZsb3cgaW52b2tlZCB1bmRlZmluZWQgYmVoYXZpb3IuCj4gPgo+ID4gQW5k IGlmIHRoYXQgaXMgYSBwcm9ibGVtLCB5b3UgdXNlIHVuc2lnbmVkIGludGVnZXJzIGluc3RlYWQg b2Ygc2lnbmVkCj4gPiBpbnRlZ2Vycy4KPiAKPiBBY3R1YWxseSwgaW4gdGhlIGNhc2Ugb2YgdGhl cmUgTGludXgga2VybmVsIHdlIGp1c3QgdGVsbCB0aGUgY29tcGlsZXIgdG8KPiBub3QgYmUgYW4g YXNzLiBXZSB1c2UKPiAKPiAgIC1mbm8tc3RyaWN0LW92ZXJmbG93CgpUaGF0IGlzIHRoZSBvbmUh Cgo+IG9yIHNvbWV0aGluZy4gSSBmb3JnZXQgdGhlIGV4YWN0IGNvbXBpbGVyIGZsYWcgbmVlZGVk IGZvciAidGhlIHN0YW5kYXJkIGlzCj4gYXMgYnJva2VuIHBpZWNlIG9mIHNoaXQgYW5kIG1hZGUg dGhpbmdzIHVuZGVmaW5lZCBmb3IgdmVyeSBiYWQgcmVhc29ucyIuCj4gCj4gU2VlIGFsc28gdGhl cmUgaWRpb3RpYyBzdGFuZGFyZCBDIGFsaWFzIHJ1bGVzLiBTYW1lIGRlYWwuCgpGb3Igd2hpY2gg d2UgdXNlIC1mbm8tc3RyaWN0LWFsaWFzaW5nLgoKPiBTbyBubywgc3RhbmRhcmRzIGFyZW4ndCB0 aGF0IGltcG9ydGFudC4gV2hlbiB0aGUgc3RhbmRhcmRzIHNjcmV3IHVwLCB0aGUKPiByaWdodCBh bnN3ZXIgaXMgbm90IHRvIHR1cm4gdGhlIG90aGVyIGNoZWVrLgoKQWdyZWVkLCBoZW5jZSBteSBj dXJyZW50IChwZXJoYXBzIHF1aXhvdGljIGFuZCBpbnNhbmUpIGF0dGVtcHQgdG8gZ2V0CnRoZSBz dGFuZGFyZCB0byBkbyBzb21ldGhpbmcgdXNlZnVsIGZvciBkZXBlbmRlbmN5IG9yZGVyaW5nLiAg QnV0IGlmCnRoYXQgZG9lc24ndCB3b3JrLCB5ZXMsIGEgZmFsbGJhY2sgcG9zaXRpb24gaXMgdG8g Z2V0IHRoZSByZWxldmFudApjb21waWxlcnMgdG8gcHJvdmlkZSBmbGFncyB0byBhdm9pZCBwcm9i bGVtYXRpYyBiZWhhdmlvciwgc2ltaWxhciB0bwotZm5vLXN0cmljdC1vdmVyZmxvdy4KCgkJCQkJ CQlUaGFueCwgUGF1bAoKPiBBbmQgdW5kZWZpbmVkIGJlaGF2aW9yIGlzIHByZXR0eSBtdWNoICph bHdheXMqIGEgc2lnbiBvZiAidGhlIHN0YW5kYXJkIGlzCj4gd3JvbmciLgo+IAo+ICAgICAgTGlu dXMKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCkxMVk0g RGV2ZWxvcGVycyBtYWlsaW5nIGxpc3QKbGx2bS1kZXZAbGlzdHMubGx2bS5vcmcKaHR0cDovL2xp c3RzLmxsdm0ub3JnL2NnaS1iaW4vbWFpbG1hbi9saXN0aW5mby9sbHZtLWRldgo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from e32.co.us.ibm.com ([32.97.110.150]:60760 "EHLO e32.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756780AbcB0XKk (ORCPT ); Sat, 27 Feb 2016 18:10:40 -0500 Received: from localhost by e32.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Sat, 27 Feb 2016 16:10:39 -0700 Date: Sat, 27 Feb 2016 15:10:33 -0800 From: "Paul E. McKenney" Subject: Re: [isocpp-parallel] Proposal for new memory_order_consume definition Message-ID: <20160227231033.GW3522@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com References: <20160218011033.GA1505@linux.vnet.ibm.com> <20160220021516.4898897.32908.5212@gmail.com> <20160220195318.GF3522@linux.vnet.ibm.com> <20160227170615.GU3522@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-arch-owner@vger.kernel.org List-ID: To: Linus Torvalds Cc: linux-arch@vger.kernel.org, Jade Alglave , p796231 , gcc@gcc.gnu.org, llvm-dev@lists.llvm.org, Luc Maranget , mingo@kernel.org, akpm@linux-foundation.org, dhowells@redhat.com, linux-kernel@vger.kernel.org, parallel@lists.isocpp.org, will.deacon@arm.com, peterz@infradead.org, Ramana.Radhakrishnan@arm.com Message-ID: <20160227231033.M1U5ioRpt0nGiFcUdRMNWffX0S9wwX-MFsSIv3bPfWI@z> On Sat, Feb 27, 2016 at 11:16:51AM -0800, Linus Torvalds wrote: > On Feb 27, 2016 09:06, "Paul E. McKenney" > wrote: > > > > > > But we do already have something very similar with signed integer > > overflow. If the compiler can see a way to generate faster code that > > does not handle the overflow case, then the semantics suddenly change > > from twos-complement arithmetic to something very strange. The standard > > does not specify all the ways that the implementation might deduce that > > faster code can be generated by ignoring the overflow case, it instead > > simply says that signed integer overflow invoked undefined behavior. > > > > And if that is a problem, you use unsigned integers instead of signed > > integers. > > Actually, in the case of there Linux kernel we just tell the compiler to > not be an ass. We use > > -fno-strict-overflow That is the one! > or something. I forget the exact compiler flag needed for "the standard is > as broken piece of shit and made things undefined for very bad reasons". > > See also there idiotic standard C alias rules. Same deal. For which we use -fno-strict-aliasing. > So no, standards aren't that important. When the standards screw up, the > right answer is not to turn the other cheek. Agreed, hence my current (perhaps quixotic and insane) attempt to get the standard to do something useful for dependency ordering. But if that doesn't work, yes, a fallback position is to get the relevant compilers to provide flags to avoid problematic behavior, similar to -fno-strict-overflow. Thanx, Paul > And undefined behavior is pretty much *always* a sign of "the standard is > wrong". > > Linus