[llvm-dev] [isocpp-parallel] Proposal for new memory_order_consume definition

[James Y Knight via llvm-dev]

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.

On Mon, Feb 29, 2016 at 2:38 PM, Lawrence Crowl via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> On 2/28/16, Linus Torvalds <torvalds at 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 at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160229/1b991fd8/attachment.html>