From owner-freebsd-current@FreeBSD.ORG Fri Feb 28 07:39:29 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 6B3B8643 for ; Fri, 28 Feb 2014 07:39:29 +0000 (UTC) Received: from gw.catspoiler.org (gw.catspoiler.org [75.1.14.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4BA2B1A68 for ; Fri, 28 Feb 2014 07:39:28 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id s1S7dKUA095981; Thu, 27 Feb 2014 23:39:24 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201402280739.s1S7dKUA095981@gw.catspoiler.org> Date: Thu, 27 Feb 2014 23:39:20 -0800 (PST) From: Don Lewis Subject: Re: firebox build fails post clang-3.4 merge To: kaduk@mit.edu In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: imb@protected-networks.net, 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: Fri, 28 Feb 2014 07:39:29 -0000 On 26 Feb, Benjamin Kaduk wrote: > On Wed, 26 Feb 2014, Don Lewis wrote: > >> On 26 Feb, Michael Butler wrote: >>> On 02/18/14 12:10, Michael Butler wrote: >>>> Is anyone else seeing firefox failing to install after the clang-3.4 >>>> merge? As in xpcshell dumping core .. >>> >>> An update .. >>> >>> Recompiling with GCC48 on -current yields the same result. Seems to run >>> correctly when invoked from the command-line but seg-faults with "errno >>> = 4" (invalid instruction) from the build >>> >>> Giving up and using the Linux port .. :-( >> >> I've also seen this problem with clang-3.4 on i386. It looks like a >> clang bug to me. Clang is putting ud2 instructions in its output which >> are guaranteed to fault when it compiles nsAppRunner.cpp. See >> . > > That would seem to indicate that clang believes the source code in > question is exercising a case which is explicitly listed as giving > undefined behavior in the language specification. Presumably that means we > need a C++ language lawyer to look over the code in question. After spending the last couple of days pounding my head on my desk, I managed to come up with a standalone test case that reproduces this problem. The source is still on the hefty side because of all the C++ template goo (but more than an order of magnitude smaller than when I started) but the assembly code is fairly small. If updated my PR with the relevant info.