Eric Gallager <eg...@gwmail.gwu.edu> wrote: > On 11/5/19, Jakub Jelinek <ja...@redhat.com> wrote: >> On Mon, Nov 04, 2019 at 04:10:27PM +0100, Martin Liska wrote: >>> libsanitizer/ChangeLog: >>> >>> 2019-11-05 Martin Liska <mli...@suse.cz> >>> >>> * 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: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78352 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. thanks Iain
