Apple's GCC 42 enhancements (was Re: [CFT] Experimental gcc update).

[Pedro Giffuni]

El 04/01/2014 5:49 p. m., Pedro Giffuni escribió:
> On 02.01.2014 16:48, David Chisnall wrote:
>> On 2 Jan 2014, at 20:22, Pedro Giffuni <pfg at 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?
>

Bah, nevermind ... it should work just fine.

Feel free to go ahead though, I don't want to play with the style on 
that particular file ;-).

> 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 ;).
>

Committed as r260311.

I am hoping to see a lot more uses of blocks/GCD in the base system now :).

Pedro.