Date: Thu, 27 Feb 2014 17:24:00 +0000 From: David Chisnall <theraven@FreeBSD.org> To: Michael Butler <imb@protected-networks.net> Cc: Don Lewis <truckman@FreeBSD.org>, freebsd-current@FreeBSD.org Subject: Re: firebox build fails post clang-3.4 merge Message-ID: <A540F9BE-19E5-4ACF-B4A1-106B894F89FA@FreeBSD.org> In-Reply-To: <530EA5CD.2070508@protected-networks.net> References: <201402270057.s1R0vkjH084327@gw.catspoiler.org> <530EA5CD.2070508@protected-networks.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 27 Feb 2014, at 02:41, Michael Butler <imb@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A540F9BE-19E5-4ACF-B4A1-106B894F89FA>