From owner-svn-src-all@FreeBSD.ORG Sun Jan 5 19:52:57 2014 Return-Path: <owner-svn-src-all@FreeBSD.ORG> Delivered-To: svn-src-all@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 D6F13B7E; Sun, 5 Jan 2014 19:52:56 +0000 (UTC) Received: from smtpauth3.wiscmail.wisc.edu (wmauth3.doit.wisc.edu [144.92.197.226]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0405E1EA8; Sun, 5 Jan 2014 19:52:56 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from avs-daemon.smtpauth3.wiscmail.wisc.edu by smtpauth3.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) id <0MYY00F001SVDO00@smtpauth3.wiscmail.wisc.edu>; Sun, 05 Jan 2014 13:52:49 -0600 (CST) X-Spam-PmxInfo: Server=avs-3, Version=6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.1.5.194517, SenderIP=0.0.0.0 X-Spam-Report: AuthenticatedSender=yes, SenderIP=0.0.0.0 Received: from wanderer.tachypleus.net (pool-72-66-107-173.washdc.fios.verizon.net [72.66.107.173]) by smtpauth3.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) with ESMTPSA id <0MYY009YC1VY5V00@smtpauth3.wiscmail.wisc.edu>; Sun, 05 Jan 2014 13:52:48 -0600 (CST) Message-id: <52C9B80E.6060100@freebsd.org> Date: Sun, 05 Jan 2014 14:52:46 -0500 From: Nathan Whitehorn <nwhitehorn@freebsd.org> User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 To: Pedro Giffuni <pfg@FreeBSD.org>, Tijl Coosemans <tijl@FreeBSD.org> Subject: Re: svn commit: r260311 - in head/contrib: gcc gcc/cp gcc/doc gcclibs/include gcclibs/libiberty References: <201401050043.s050hSMI089553@svn.freebsd.org> <20140105124557.5dd8395a@kalimero.tijl.coosemans.org> <52C985C7.9060406@FreeBSD.org> <20140105174221.220d9a13@kalimero.tijl.coosemans.org> <52C9B652.9040102@FreeBSD.org> In-reply-to: <52C9B652.9040102@FreeBSD.org> X-Enigmail-Version: 1.6 Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, bapt@FreeBSD.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" <svn-src-all.freebsd.org> List-Unsubscribe: <http://lists.freebsd.org/mailman/options/svn-src-all>, <mailto:svn-src-all-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/svn-src-all/> List-Post: <mailto:svn-src-all@freebsd.org> List-Help: <mailto:svn-src-all-request@freebsd.org?subject=help> List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/svn-src-all>, <mailto:svn-src-all-request@freebsd.org?subject=subscribe> X-List-Received-Date: Sun, 05 Jan 2014 19:52:57 -0000 On 01/05/14 14:45, Pedro Giffuni wrote: > On 05.01.2014 11:42, Tijl Coosemans wrote: >> On Sun, 05 Jan 2014 11:18:15 -0500 Pedro Giffuni wrote: >>> On 05.01.2014 06:45, Tijl Coosemans wrote: >>>> On Sun, 5 Jan 2014 00:43:28 +0000 (UTC) Pedro F. Giffuni wrote: >>>>> Author: pfg >>>>> Date: Sun Jan 5 00:43:28 2014 >>>>> New Revision: 260311 >>>>> URL: http://svnweb.freebsd.org/changeset/base/260311 >>>>> >>>>> Log: >>>>> gcc: Add support for Apple's Block extension >>>>> Block objects [1] are a C-level syntactic and runtime >>>>> feature. They >>>>> are similar to standard C functions, but in addition to >>>>> executable >>>>> code they may also contain variable bindings to automatic (stack) >>>>> or managed (heap) memory. A block can therefore maintain a set of >>>>> state (data) that it can use to impact behavior when executed. >>>>> This port is based on Apple's GCC 5646 with some bugfixes >>>>> from >>>>> Apple GCC 5666.3. It has some small differences with the support >>>>> in clang, which remains the recommended compiler. >>>>> Perhaps the most notable difference is that in GCC that >>>>> __block >>>>> is not actually a keyword, but a macro. There will be workaround >>>>> for this issue in a near future. Other issues can be consulted in >>>>> the clang documentation [2] >>>>> For better compatiblity with Apple's GCC and llvm-gcc some >>>>> related >>>>> fixes and features from Apple have been included. Support for the >>>>> non-standard nested functions in GCC is now off by default. >>>> Some ports use nested functions. >>> We now have the Apple-GCC compatible -fnested-functions, >>> however, this is of little relevance because on FreeBSD 10+ >>> the default compiler (clang) doesn't support them at all. >>> >>> Most such ports should already be using the fsf gcc but >>> I am not going to find out which do or dont; I simply won't >>> merge this to 9 until there is a good reason to do it. * >> Doesn't this affect architectures where clang isn't the default yet? > Yes, it may affect a small number of ports in tier 2 platforms. The > fix is rather trivial though and gcc is rather verbal about it. > > For tier 2 platforms it would be especially ugly to have people build > a new version of gcc to run such ports. > > >> You can grep the ports tree for nestedfct which currently implies >> USE_GCC=any, i.e. use base system gcc when available, otherwise use >> lang/gcc port. Do you think it's best to change this into USE_GCC=yes, >> i.e. always use lang/gcc port? > > That search would be big: many ports (OpenOffice for example) can > build with gcc 4.2 but it doesn't use nested functions. The most > reliable way to catch them all would be to make an experimental run on > the ports tree but we currently don't have that capacity for tier 2 > platforms. > > I think it would be best to have upstream ports learn about > -fnested-functions (stuff that works on Apple should already know) and > on the long run hope that upstream authors will avoid the feature > altogether. > > Pedro. It's also worth pointing out that our default ports GCC (4.6) does not build on some of these platforms (PowerPC64, for example), so requiring it would unconditionally break them. lang/gcc48 does, however, at least on PPC64, so it might be worth switching the default. -Nathan