[LLVMdev] C as used/implemented in practice: analysis of responses

[Russell Wallace]

Not all code needs to be moved between compilers.

That having been said, if my proposal were implemented, you would still be
perfectly free to tell people 'you're doing it wrong, you shouldn't
actually depend on things the standard doesn't cover' (even though in
practice, people use compiler extensions, system specific code and suchlike
all the time, and nobody seems to think this is a reason such things
shouldn't be provided).

Even if you want to have the compiler warn at compile time about code that
depends on undefined behaviour (in cases where it can deduce that such is
occurring), that's okay.

But having programs miscompiled so that they silently fail, in many cases
starting only years after the code in question was written, is very much
not okay. That's far worse than documented portability problems.

On Wed, Jul 1, 2015 at 7:08 PM, Tim Northover <t.p.northover at gmail.com>
wrote:

> > 1. The performance gain from this on real programs is small. I will
> suggest
> > that the total performance gain from optimisations that rely on
> exploiting
> > undefined behaviour - let's call them monkey's paw optimisations for
> short -
> > is practically never more than a few percent, and often less than one
> > percent.
> >
> > 2. For most programs, having the program work is worth far more than
> having
> > it run a few percent faster.
>
> Which may or may not be fine until you decide to switch
> compilers/platforms. Encouraging programmers to use Clang-specific
> interpretations of these constructs would promote vendor lock-in and
> be a blow for portability, which I think is worse than UB. At least
> now we can tell people "you're doing it wrong".
>
> Cheers.
>
> Tim.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150701/122ab860/attachment.html>