[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAA+UVZT9vK8CZdRr8P9=cDT6OhCz=zieHY81txnNdAAF4v_sPA@mail.gmail.com>
Date: Mon, 29 Feb 2016 11:38:33 -0800
From: Lawrence Crowl <Lawrence@...wl.org>
To: parallel@...ts.isocpp.org
Cc: Markus Trippelsdorf <markus@...ppelsdorf.de>,
"linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
"gcc@....gnu.org" <gcc@....gnu.org>,
Jade Alglave <j.alglave@....ac.uk>, llvm-dev@...ts.llvm.org,
Will Deacon <will.deacon@....com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
David Howells <dhowells@...hat.com>,
Peter Zijlstra <peterz@...radead.org>,
Ramana Radhakrishnan <Ramana.Radhakrishnan@....com>,
Luc Maranget <luc.maranget@...ia.fr>,
Andrew Morton <akpm@...ux-foundation.org>,
Ingo Molnar <mingo@...nel.org>
Subject: Re: [isocpp-parallel] Proposal for new memory_order_consume definition
On 2/28/16, Linus Torvalds <torvalds@...ux-foundation.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.
--
Lawrence Crowl
Powered by blists - more mailing lists