From owner-freebsd-current@FreeBSD.ORG Sun Jan 6 16:51:14 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6E162254; Sun, 6 Jan 2013 16:51:14 +0000 (UTC) (envelope-from theraven@freebsd.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) by mx1.freebsd.org (Postfix) with ESMTP id 308F191E; Sun, 6 Jan 2013 16:51:13 +0000 (UTC) Received: from [192.168.0.2] (cpc10-cmbg15-2-0-cust123.5-4.cable.virginmedia.com [86.30.246.124]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id r06GpBe9033259 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Sun, 6 Jan 2013 16:51:12 GMT (envelope-from theraven@freebsd.org) Subject: Re: clang 3.2 RC2 miscompiles libgcc? Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: David Chisnall In-Reply-To: <50E9AAF4.209@freebsd.org> Date: Sun, 6 Jan 2013 16:51:11 +0000 Content-Transfer-Encoding: 7bit Message-Id: <78AC11F6-7AAE-449D-9ED1-DB5B207152DA@freebsd.org> References: <20121227150724.GA1431@mole.fafoe.narf.at> <50DC65F5.6060004@freebsd.org> <50E0BD66.4070609@FreeBSD.org> <20130102135950.GA1464@mole.fafoe.narf.at> <20130104154940.GD1430@mole.fafoe.narf.at> <20130106141708.GA1418@mole.fafoe.narf.at> <50E9AAF4.209@freebsd.org> To: Nathan Whitehorn X-Mailer: Apple Mail (2.1278) Cc: Stefan Farfeleder , Dimitry Andric , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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: Sun, 06 Jan 2013 16:51:14 -0000 On 6 Jan 2013, at 16:48, Nathan Whitehorn wrote: > No. It's completely broken at all optimization levels. There do not > appear to be any flags that change the behavior. Building unwind-dw2.c > either with gcc or with the previous import of clang in our tree does > fix it, however. Do you have an LLVM PR# for this that I can follow? David