On 02.01.2014 16:48, David Chisnall wrote:
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.
Thank you for the hint. Is there some way to have this happen
only for our GCC-4.2.1 but not for clang or newer gcc?
I am getting ready to commit the blocks support [1] but we can
leave the macro magic for later, while there is some consensus
on the dark arts involved ;).
Pedro.
[1] I ran buildworld and rebuilt boost and some ports with the modified
compiler ... so far, so good. I don't think an exp-run is necessary
since the blocks stuff is not yet being used for any port.
_______________________________________________
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"
