svn commit: r260311 - in head/contrib: gcc gcc/cp gcc/doc gcclibs/include gcclibs/libiberty

[Nathan Whitehorn]

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