Eric Gallager <> wrote:

> On 11/5/19, Jakub Jelinek <> wrote:
>> On Mon, Nov 04, 2019 at 04:10:27PM +0100, Martin Liska wrote:
>>> libsanitizer/ChangeLog:
>>> 2019-11-05  Martin Liska  <>
>>>     * all source files: Merge from upstream r375507.
>>> ---
>>> libsanitizer/BlocksRuntime/Block.h            |   59 +
>>> libsanitizer/BlocksRuntime/Block_private.h    |  179 ++
>> Do we really need this?

probably not, 

I’ve been tied up with WG21, so not properly reviewed the libsanitizer
merge yet..  However, I have a note to myself to check the *existing*
interface that GCC is emitting for the facility on Darwin, since it differs
from the one emitted by clang (that might/might not be imporant, it’s not
yet analysed).

> So, maybe we don't need this for the sanitizer itself, but if the
> sanitizers now come with their own copy of the Blocks Runtime...
> couldn't that be the solution as to where to take our blocks support
> library for GCC proper from?

No, this issue is not the absence of a blocks runtime (at least, not on
Darwin) the issue is that the compiler support is missing.

>> I mean, couldn't we wrap this Block.h include with #ifdef __BLOCKS__ or so
>> as a local patch (at least for now)?
> This is bug 78352 btw:

I haven’t got anything mature enough to post for inclusion in GCC-10, the last
6 months have been “playing catch up” and just didn’t leave enough time for
this, sadly.


Reply via email to