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.
_______________________________________________
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
