This is the mail archive of the
mailing list for the GCC project.
Re: [isocpp-parallel] Proposal for new memory_order_consume definition
- From: Lawrence Crowl <Lawrence at Crowl dot org>
- To: parallel at lists dot isocpp dot org
- Cc: Markus Trippelsdorf <markus at trippelsdorf dot de>, "linux-arch at vger dot kernel dot org" <linux-arch at vger dot kernel dot org>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, Jade Alglave <j dot alglave at ucl dot ac dot uk>, llvm-dev at lists dot llvm dot org, Will Deacon <will dot deacon at arm dot com>, Linux Kernel Mailing List <linux-kernel at vger dot kernel dot org>, David Howells <dhowells at redhat dot com>, Peter Zijlstra <peterz at infradead dot org>, Ramana Radhakrishnan <Ramana dot Radhakrishnan at arm dot com>, Luc Maranget <luc dot maranget at inria dot fr>, Andrew Morton <akpm at linux-foundation dot org>, Ingo Molnar <mingo at kernel dot org>
- Date: Mon, 29 Feb 2016 11:38:33 -0800
- 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> <20160228082702 dot GA300 at x4> <CA+55aFyauwKmUdxfrKcy5Q2kvdej5fWt6xL+amVyPFhzmHMcsg at mail dot gmail dot com>
On 2/28/16, Linus Torvalds <firstname.lastname@example.org> wrote:
> The fact is, undefined compiler behavior is never a good idea. Not for
> serious projects.
Actually, undefined behavior is essential for serious projects, but
not for the reasons mentioned.
If the language has no undefined behavior, then from the compiler's view,
there is no such thing as a bad program. All programs will compile and
enter functional debug (possibly after shipping to customer). On the
other hand, a language with undefined behavior makes it possible for
compilers (and their run-time support) to identify a program as wrong.
The problem with the latest spate of compiler optimizations was not the
optimization, but the lack of warnings about exploiting undefined behavior.