Date: Sat, 04 Jan 2014 23:35:53 -0500 From: Pedro Giffuni <pfg@FreeBSD.org> To: David Chisnall <theraven@FreeBSD.org> Cc: toolchain@FreeBSD.org Subject: Re: Apple's GCC 42 enhancements (was Re: [CFT] Experimental gcc update). Message-ID: <52C8E129.3030106@FreeBSD.org> In-Reply-To: <52C88FDD.7090701@FreeBSD.org> References: <528A924A.8050904@FreeBSD.org> <529127F8.5080606@FreeBSD.org> <3826345B-E783-43C7-B4AB-A05C95C1A8A2@FreeBSD.org> <52C5CA79.90706@FreeBSD.org> <C6FA2135-F549-4615-AC77-3909377C8887@FreeBSD.org> <52C88FDD.7090701@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?52C8E129.3030106>