From owner-freebsd-current@FreeBSD.ORG Thu Feb 27 17:24:11 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 48589EA; Thu, 27 Feb 2014 17:24:11 +0000 (UTC) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 16D7A1F59; Thu, 27 Feb 2014 17:24:09 +0000 (UTC) Received: from [192.168.0.7] (cpc28-cmbg15-2-0-cust64.5-4.cable.virginm.net [86.27.189.65]) (authenticated bits=0) by theravensnest.org (8.14.7/8.14.5) with ESMTP id s1RHO5YH086788 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 27 Feb 2014 17:24:07 GMT (envelope-from theraven@FreeBSD.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: firebox build fails post clang-3.4 merge From: David Chisnall In-Reply-To: <530EA5CD.2070508@protected-networks.net> Date: Thu, 27 Feb 2014 17:24:00 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201402270057.s1R0vkjH084327@gw.catspoiler.org> <530EA5CD.2070508@protected-networks.net> To: Michael Butler X-Mailer: Apple Mail (2.1827) Cc: Don Lewis , freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 17:24:11 -0000 On 27 Feb 2014, at 02:41, Michael Butler = wrote: > .. 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