On 27 Feb 2014, at 02:41, Michael Butler <i...@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.
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"