From owner-svn-src-head@FreeBSD.ORG Sun Jan 5 20:28:27 2014 Return-Path: Delivered-To: svn-src-head@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 51B5E92F for ; Sun, 5 Jan 2014 20:28:27 +0000 (UTC) Received: from nm31.bullet.mail.bf1.yahoo.com (nm31.bullet.mail.bf1.yahoo.com [72.30.239.198]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CB30010FE for ; Sun, 5 Jan 2014 20:28:26 +0000 (UTC) Received: from [98.139.212.151] by nm31.bullet.mail.bf1.yahoo.com with NNFMP; 05 Jan 2014 20:22:34 -0000 Received: from [68.142.230.77] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 05 Jan 2014 20:22:34 -0000 Received: from [127.0.0.1] by smtp234.mail.bf1.yahoo.com with NNFMP; 05 Jan 2014 20:22:34 -0000 X-Yahoo-Newman-Id: 291346.19202.bm@smtp234.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: p66IlJMVM1kQPUkGdeEyLD1UxY8IWVk_MEZVZthMxTAqvRq j8OUHn.KpoDy9DKyYVgydzAVoLbNZwK.uacSkUkda3nxOFv2QtsimycSBch. lWXDdHDUhv9Khe2LDIk4ImkWbIZjoXVkHD09vbZU28bBdhzW6Ge5E7r.fALk Yk2sFU9aCXzfuFydRJTE3N5pYRKFeoX6xIElotK60xchFUwcm5KLfJ5ZZnf7 GzyetIEF20qgUcBlN8BSRFzZMa8Ke6erCdts9WYLA_SHkYyfLEjSHFiwfvcV BI_Pa8vKq536hQBLP7dCe4t7HRi45i5ohnfRYmBJ7b6pukgqLPp6ioBbDlv3 ZimSF50IA7L0dtPJvaGL_BtaGKsD9yHk1mTVNrEMi9dCrjEG7rIHQH2ro9m3 z2jAvllYOtcV35WQXcc.Py.7RX5MS94TiX1u5ist9Pkx33O3tB5gJSFjO96B NUmNJHmcLzDuobcvqvtdA5p5xOJQEEZHBjmS8qSEJ12KmUxgsuRcmAIZAjvZ 1GW.ZTKq.dfZaFOcsq._Ms_JYb8RLNPrIaQ4nvzeaBYATTp2OPkqe_CDCY8u Qid9JXB7B5wtiqb1ZKH0maJezen5ah25YyiWdVKqwk.lJMYsThiGGYKcWeoP 6oM1lLEu6hXLhrI7D2LUO0bJY7hk- X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf X-Rocket-Received: from [192.168.0.102] (pfg@190.157.126.109 with plain [63.250.193.228]) by smtp234.mail.bf1.yahoo.com with SMTP; 05 Jan 2014 20:22:34 +0000 UTC Message-ID: <52C9BF06.5040301@FreeBSD.org> Date: Sun, 05 Jan 2014 15:22:30 -0500 From: Pedro Giffuni User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Nathan Whitehorn , Tijl Coosemans 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> <52C9B80E.6060100@freebsd.org> In-Reply-To: <52C9B80E.6060100@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, bapt@FreeBSD.org X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jan 2014 20:28:27 -0000 On 05.01.2014 14:52, Nathan Whitehorn wrote: > 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. The whole idea of this commit is to make gcc behave more like clang so that we can start using the new features in base. For now just adding -fnested-functions on a small number of ports (hopefully nothing big/important) is probably not a huge sacrifice. When PPC64 moves to clang we will have to find a real fix for the issue so leaving the switch off is a good way to detect the trouble early. Regards, Pedro.