Re: firebox build fails post clang-3.4 merge

On 27 Feb 2014, at 02:41, Michael Butler <imb_at_protected-networks.net> wrote:

> <sigh> .. way back in the late 70's or maybe early 80's when I was
> actually doing some work on compilers, we had a saying: "produce correct
> code even if it's not optimal or exit and tell the user why".

In the late '70s, the number of transforms that a compiler could do were quite limited.  By the time the code gets to the back end in a modern compiler, it is often very difficult to map back to the source code and print a diagnostic more helpful than 'something in your program was undefined behaviour'.  This is why clang includes both static and dynamic checkers for undefined behaviour, in the form of the static analyser (you do run it on all code you right, don't you?) and the undefined behaviour sanitiser.

LLVM uses ud2 for the trap intrinsic.  This can be generated for several reasons, for example:

- __builtin_trap() in the source code (sometimes used to trigger immediate termination when the program detects that it is in an indeterminate state)

- __builtin_unreachable() in some source code, which turns out to be reachable after all.  This builtin is used to produce better code by telling the compiler that certain code paths can't possibly be reached, but sometimes the compiler will leave in dynamic checks to abort if it detects that something that the user flagged as unreachable actually wasn't.

- Control flow hits a code path that the language semantics say is undefined or impossible.  This is generally considered better than continuing in an undefined state, on the basis that it's much easier to exploit a program that is running in an undefined state than one that has just exited.

- There is a compiler bug.

David