This is the mail archive of the
mailing list for the GCC project.
Re: [isocpp-parallel] Proposal for new memory_order_consume definition
- From: Markus Trippelsdorf <markus at trippelsdorf dot de>
- To: paulmck at linux dot vnet dot ibm dot com
- Cc: Linus Torvalds <torvalds at linux-foundation dot org>, linux-arch at vger dot kernel dot org, gcc at gcc dot gnu dot org, parallel at lists dot isocpp dot org, llvm-dev at lists dot llvm dot org, will dot deacon at arm dot com, linux-kernel at vger dot kernel dot org, dhowells at redhat dot com, peterz at infradead dot org, Ramana dot Radhakrishnan at arm dot com, Luc Maranget <luc dot maranget at inria dot fr>, akpm at linux-foundation dot org, Jade Alglave <j dot alglave at ucl dot ac dot uk>, mingo at kernel dot org
- Date: Sun, 28 Feb 2016 09:27:02 +0100
- Subject: Re: [isocpp-parallel] Proposal for new memory_order_consume definition
- Authentication-results: sourceware.org; auth=none
- References: <20160218011033 dot GA1505 at linux dot vnet dot ibm dot com> <20160220021516 dot 4898897 dot 32908 dot 5212 at gmail dot com> <20160220195318 dot GF3522 at linux dot vnet dot ibm dot com> <CAPUmR1bw=N4NkjAK1zn_X0+84KEaEAM6HZCHZJy_txqC9hMgSg at mail dot gmail dot com> <20160227170615 dot GU3522 at linux dot vnet dot ibm dot com> <CA+55aFyHmykKc=YybJMo9ZUO352MY5noJVB4-K1Lkjmw4UHXfA at mail dot gmail dot com> <20160227231033 dot GW3522 at linux dot vnet dot ibm dot com>
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" <email@example.com>
> > 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