From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757073AbcB1I1J (ORCPT ); Sun, 28 Feb 2016 03:27:09 -0500 Received: from ud10.udmedia.de ([194.117.254.50]:50273 "EHLO mail.ud10.udmedia.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756977AbcB1I1I (ORCPT ); Sun, 28 Feb 2016 03:27:08 -0500 Date: Sun, 28 Feb 2016 09:27:02 +0100 From: Markus Trippelsdorf To: paulmck@linux.vnet.ibm.com Cc: Linus Torvalds , 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 Subject: Re: [isocpp-parallel] Proposal for new memory_order_consume definition Message-ID: <20160228082702.GA300@x4> 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> <20160227231033.GW3522@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160227231033.GW3522@linux.vnet.ibm.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2016.02.27 at 15:10 -0800, Paul E. McKenney via llvm-dev wrote: > 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. Do not forget -fno-delete-null-pointer-checks. So the kernel obviously is already using its own C dialect, that is pretty far from standard C. All these options also have a negative impact on the performance of the generated code. -- Markus