Re: Apple's GCC 42 enhancements (was Re: [CFT] Experimental gcc update).
On 02.01.2014 15:22, Pedro Giffuni wrote: Heloo and Happy New Year! On 24.11.2013 07:54, David Chisnall wrote: On 23 Nov 2013, at 22:11, Pedro Giffunip...@freebsd.org wrote: I have particular interest in -fwritable-strings and the block support, mostly with the idea of making our gcc somewhat more compatible to clang. I would absolutely love to see our GCC have blocks support. It would be very nice to be able to use blocks in libc. It took me a while and I still have to do more review, but I finally have a patch for blocks support in gcc http://people.freebsd.org/~pfg/patches/gcc/gcc-blocks.patch (this only applies against -current for now) Forgot to mention ... I also have a patch to add support for private extern and while libdispatch can use them, it looks like that it is deprecated in favor of the visibility attributes so I don't have plans to commit it. I started patches for pascal strings and writable strings but they cause segfaults and are also officially deprecated so I won't be doing those either. Other than those, Apple has some bug fixes and support for more warnings that are also available in clang. Not sure if I want to spend more time in gcc though :-P. Regards, Pedro. ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: Apple's GCC 42 enhancements (was Re: [CFT] Experimental gcc update).
On 2 Jan 2014, at 20:22, Pedro Giffuni p...@freebsd.org wrote:
The behaviour is consistent with llvm-gcc though, as explained here:
https://bugs.launchpad.net/ubuntu/+source/llvm-gcc-4.2/+bug/483679
looking at the LLVM/Clang documentation
(http://clang.llvm.org/doxygen/InitPreprocessor_8cpp-source.html) shows that
__block is not actually a keyword, but a macro that is defined to be
__attribute__((__blocks__(byref))).
Not sure what to do about it, I had added a #define for it in Block.h since
you have to link with -lBlocksRuntime anyways, but not everything includes
Block.h (surely not the libdispatch tests).
Probably the best solution is to put this in cdefs.h:
#if defined(__BLOCKS__) !defined(__block)
# define __block __attribute__((__blocks__(byref)))
#endif
(With the indentation changed to make it harder to read, as per style(9)). I
believe __BLOCKS__ is supported by clang, although testing for it is
discouraged in favour of the __has_{feature,extension} mechanism.
David
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: Apple's GCC 42 enhancements (was Re: [CFT] Experimental gcc update).
On 23 Nov 2013, at 22:11, Pedro Giffuni p...@freebsd.org wrote: I have particular interest in -fwritable-strings and the block support, mostly with the idea of making our gcc somewhat more compatible to clang. I would absolutely love to see our GCC have blocks support. It would be very nice to be able to use blocks in libc. I have some macros that allow code to call blocks even when compiled with a compiler that doesn't support them, but having native blocks support would be fantastic. It's worth noting that Apple's libc includes a few _b variants of standard library functions: scandir_b err_set_exit_b fts_open_b glob_b atexit_b bsearch_b heapsort_b mergesort_b psort_b qsort_b These all do the same as their non-_b-suffixed equivalents, but take a block as an argument instead of a function pointer. Adding them has been on my todo list for a while, and this would give me a strong incentive to do so... David ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: Apple's GCC 42 enhancements (was Re: [CFT] Experimental gcc update).
On Nov 24, 2013, at 5:54 AM, David Chisnall wrote: On 23 Nov 2013, at 22:11, Pedro Giffuni p...@freebsd.org wrote: I have particular interest in -fwritable-strings and the block support, mostly with the idea of making our gcc somewhat more compatible to clang. I would absolutely love to see our GCC have blocks support. It would be very nice to be able to use blocks in libc. I have some macros that allow code to call blocks even when compiled with a compiler that doesn't support them, but having native blocks support would be fantastic. It's worth noting that Apple's libc includes a few _b variants of standard library functions: scandir_b err_set_exit_b fts_open_b glob_b atexit_b bsearch_b heapsort_b mergesort_b psort_b qsort_b These all do the same as their non-_b-suffixed equivalents, but take a block as an argument instead of a function pointer. Adding them has been on my todo list for a while, and this would give me a strong incentive to do so... Cool! Any chance clang supports this Apple extension? :) Warner ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: Apple's GCC 42 enhancements (was Re: [CFT] Experimental gcc update).
On 24.11.2013 10:11, Warner Losh wrote: On Nov 24, 2013, at 5:54 AM, David Chisnall wrote: On 23 Nov 2013, at 22:11, Pedro Giffuni p...@freebsd.org wrote: I have particular interest in -fwritable-strings and the block support, mostly with the idea of making our gcc somewhat more compatible to clang. I would absolutely love to see our GCC have blocks support. It would be very nice to be able to use blocks in libc. I have some macros that allow code to call blocks even when compiled with a compiler that doesn't support them, but having native blocks support would be fantastic. It's worth noting that Apple's libc includes a few _b variants of standard library functions: scandir_b err_set_exit_b fts_open_b glob_b atexit_b bsearch_b heapsort_b mergesort_b psort_b qsort_b These all do the same as their non-_b-suffixed equivalents, but take a block as an argument instead of a function pointer. Adding them has been on my todo list for a while, and this would give me a strong incentive to do so... Nice! Cool! Any chance clang supports this Apple extension? :) clang, of course, supports it. The upstream gcc doesn't (they are considering it but apparently they can't reuse the GPLv2 code). Bringing blocks support means we are forking gcc but that doesn't really worry me since we are not getting any support from the FSF anyways. There is a fork of Android's gcc that supports objc and they did the heavy lifting. I have a patch from there but I still have to clean it up. Pedro. ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Apple's GCC 42 enhancements (was Re: [CFT] Experimental gcc update).
Hi; I committed the patches from Google's old gcc 4.2.1. I would like to work slowly on bringing some changes from Apple's GCC now. I have particular interest in -fwritable-strings and the block support, mostly with the idea of making our gcc somewhat more compatible to clang. Maybe someone is interested in something else so I thought I would share this site I set up: http://code.google.com/p/apple-gcc/ I basically uploaded several apple gcc42 versions as SVN revisions so I can check changes between different versions and generate diffs. If I have time I would also like to merge back some of our fixes to Apple's GCC but for now it is just a tool to examine the existing GPLv2 changes from Apple. Enjoy, Pedro. ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
