From owner-freebsd-current@FreeBSD.ORG Fri Aug 30 14:55:46 2013 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 ESMTP id DCDC57DF; Fri, 30 Aug 2013 14:55:46 +0000 (UTC) (envelope-from theraven@FreeBSD.org) 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 A7A2D2B17; Fri, 30 Aug 2013 14:55:46 +0000 (UTC) Received: from c120.sec.cl.cam.ac.uk (c120.sec.cl.cam.ac.uk [128.232.18.120]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id r7UEtima009547 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 30 Aug 2013 14:55:45 GMT (envelope-from theraven@FreeBSD.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: GCC withdraw From: David Chisnall In-Reply-To: <5220B1F3.1030807@freebsd.org> Date: Fri, 30 Aug 2013 15:55:43 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130822200902.GG94127@funkthat.com> <201308291057.43027.jhb@freebsd.org> <8F836479-BC3A-4679-A7AA-3BCDD34AE6C5@FreeBSD.org> <52204746.2070900@freebsd.org> <5220B1F3.1030807@freebsd.org> To: Nathan Whitehorn X-Mailer: Apple Mail (2.1508) Cc: "Sam Fourman Jr." , toolchain@FreeBSD.org, "freebsd-current@freebsd.org CURRENT" , Boris Samorodov , FreeBSD Current 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: Fri, 30 Aug 2013 14:55:46 -0000 On 30 Aug 2013, at 15:53, Nathan Whitehorn = wrote: > So the real driver here is switching to libc++. Is there really no way > at all to use it with gcc? If, even with hacking, we could arrange = that > to work then it seems that all of our problems would go away. If we can make our g++ compile C++11 code, then we can compile libc++ = with g++. This support requires significant modifications to the parser = (it adds a second Turing-complete compile-time language, for one...) and = so retrofitting C++11 support to g++ 4.2.1 is not going to happen. It's = taken upstream gcc a couple of years to get to the required level of = support. We don't have the manpower to replicate this. David