[LLVMdev] C as used/implemented in practice: analysis of responses (original) (raw)

Russell Wallace russell.wallace at gmail.com
Wed Jul 1 11:24:13 PDT 2015

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>

More information about the llvm-dev mailing list