From owner-freebsd-current@FreeBSD.ORG Tue Jul 22 19:06:03 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A1B2FBE4; Tue, 22 Jul 2014 19:06:03 +0000 (UTC) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2B1DF2927; Tue, 22 Jul 2014 19:06:02 +0000 (UTC) X-AuditID: 1209190d-f79c06d000002f07-27-53ceb619e14e Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id EE.15.12039.916BEC35; Tue, 22 Jul 2014 15:06:01 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id s6MJ60Lq011004; Tue, 22 Jul 2014 15:06:00 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s6MJ5wNv011675 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 22 Jul 2014 15:06:00 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s6MJ5wpQ029211; Tue, 22 Jul 2014 15:05:58 -0400 (EDT) Date: Tue, 22 Jul 2014 15:05:58 -0400 (EDT) From: Benjamin Kaduk To: Dimitry Andric Subject: Re: clang assertion failure+coredump in clang 3.4.1 In-Reply-To: <8B11DC31-9BAC-4C46-89C7-8F13ABCCD07D@FreeBSD.org> Message-ID: References: <8B11DC31-9BAC-4C46-89C7-8F13ABCCD07D@FreeBSD.org> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKIsWRmVeSWpSXmKPExsUixG6nriu57Vywwby1fBYTrvxgsljStY/R gcljxqf5LAGMUVw2Kak5mWWpRfp2CVwZz2cHFCzlq+j9KtHAeIa7i5GDQ0LAROL4CY0uRk4g U0ziwr31bF2MXBxCArOZJLrW/oRyNjJKvPl/hh3COcQkcWzyQSingVHi7PN9zCD9LALaEm/6 dzOB2GwCKhIz32xkA7FFgOyPz9rZQNYxC4hLvOxXAgkLC9hIdOz9BVbOKWAv8e/mX0YQm1fA UeLl44NgrUICJRKn1m9gB7FFBXQkVu+fwgJRIyhxcuYTMJtZwFLi3J/rbBMYBWchSc1CklrA yLSKUTYlt0o3NzEzpzg1Wbc4OTEvL7VI10gvN7NELzWldBMjKDQ5JXl3ML47qHSIUYCDUYmH t6DmXLAQa2JZcWXuIUZJDiYlUd66tUAhvqT8lMqMxOKM+KLSnNTiQ4wSHMxKIrzRrUA53pTE yqrUonyYlDQHi5I471trq2AhgfTEktTs1NSC1CKYrAwHh5IE75stQI2CRanpqRVpmTklCGkm Dk6Q4TxAw8FqeIsLEnOLM9Mh8qcYFaXEeblBEgIgiYzSPLheWOp4xSgO9Iowr+hWoCoeYNqB 634FNJgJaHBR5mmQwSWJCCmpBkanpRt0n86qvn3sWsv3s2kl/ye8X8tYcaCSa961SOfVUS7y M8P2vbHmW33vUnxedejnfxcnMfNLX7ORq8wM4rxfZLh28zX2Gzv6+lWdjgZtOrLhRrhLbeHs oy5lS0U2qId0F8qXdIVvkDOQmac9I/3k9p6ODUuOd7Q7sN2tdp3p37fb8/eq1GtKLMUZiYZa zEXFiQCA4e+k+AIAAA== Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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: Tue, 22 Jul 2014 19:06:03 -0000 Hi Dimitry, On Tue, 22 Jul 2014, Dimitry Andric wrote: > On 22 Jul 2014, at 00:34, Benjamin Kaduk wrote: >> Building some out-of-tree software with a rather long set of compiler flags, I can reliably get our clang to crash. >> The system is current as of r267362 (June 11), with clang reporting itself as FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 >> Target: x86_64-unknown-freebsd11.0 >> (freefall's clang crashes as well.) >> >> Unfortunately, I don't have debug symbols around for that clang binary. >> If someone does have a clang with debug symbols handy, I'd be interested in seeing the backtrace. >> >> The processed source file and invocation shell script may be found at: >> http://web.mit.edu/kaduk/Public/clang/dumptool-09e584.c (1.1M) >> http://web.mit.edu/kaduk/Public/clang/dumptool-09e584.sh > > Hi Ben, > > I was able to reproduce the assertion, even with clang trunk. It is > apparently caused by the implementation of the -Wconsumed warning, which > is enabled in your case because you had used -Weverything. > > I have reported an upstream bug with a reduced test case here: > > http://llvm.org/PR20402 Thank you very much! I was planning to try to reproduce on clang trunk and reduce the test case, but I think you are much more practiced at doing so than I am ;) > Meanwhile, you can work around the assertion by adding -Wno-consumed to > your compilation flags. I will do so, thanks. As you may have guessed from the compiler command line, I'm enabled -Weverything for development and am disabling the pieces that cause annoyance and/or too much spew. The openafs build system interacts in an exciting way with bsd.kmod.mk, passing through my -Weverything and also taking the kernel's -Werror... -Ben