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.


freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to