This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [llvm-dev] [isocpp-parallel] Proposal for new memory_order_consume definition
- From: James Y Knight <jyknight at google dot com>
- To: Lawrence Crowl <Lawrence at crowl dot org>
- Cc: parallel at lists dot isocpp dot org, "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>, llvm-dev <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>, Jade Alglave <j dot alglave at ucl dot ac dot uk>, Ingo Molnar <mingo at kernel dot org>, Markus Trippelsdorf <markus at trippelsdorf dot de>
- Date: Mon, 29 Feb 2016 16:12:41 -0500
- Subject: Re: [llvm-dev] [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> <CAA+UVZT9vK8CZdRr8P9=cDT6OhCz=zieHY81txnNdAAF4v_sPA at mail dot gmail dot com>
No, you really don't need undefined behavior in the standard in order
to enable bug-finding.
The standard could've (and still could...) make signed integer
overflow "implementation-defined" rather than "undefined". Compilers
would thus be required to have *some documented meaning* for it (e.g.
wrap 2's-complement, wrap 1's-complement, saturate to min/max, trap,
or whatever...), but must not have the current "Anything goes! I can
set your cat on fire if the optimizer feels like it today!" behavior.
Such a change to the standard would not reduce any ability to do error
checking, as compilers that want to be helpful could perfectly-well
define it to trap at runtime when given certain compiler flags, and
perfectly well warn you of your dependence upon unportable
implementation-defined behavior (or, that your program is going to
trap), at build-time.
[Sending again as a plain-text email, since a bunch of mailing lists
apparently hate on multipart messages that even contain a text/html
part...]
On Mon, Feb 29, 2016 at 2:38 PM, Lawrence Crowl via llvm-dev
<llvm-dev@lists.llvm.org> wrote:
> On 2/28/16, Linus Torvalds <torvalds@linux-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
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev