Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 5 Jan 2014 17:42:21 +0100
From:      Tijl Coosemans <tijl@FreeBSD.org>
To:        Pedro Giffuni <pfg@FreeBSD.org>
Cc:        svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, bapt@FreeBSD.org
Subject:   Re: svn commit: r260311 - in head/contrib: gcc gcc/cp gcc/doc gcclibs/include gcclibs/libiberty
Message-ID:  <20140105174221.220d9a13@kalimero.tijl.coosemans.org>
In-Reply-To: <52C985C7.9060406@FreeBSD.org>
References:  <201401050043.s050hSMI089553@svn.freebsd.org> <20140105124557.5dd8395a@kalimero.tijl.coosemans.org> <52C985C7.9060406@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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?
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?



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140105174221.220d9a13>