This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH 1/5] Libsanitizer: merge from trunk with merge.sh.
Eric Gallager <egall@gwmail.gwu.edu> wrote:
> On 11/5/19, Jakub Jelinek <jakub@redhat.com> wrote:
>> On Mon, Nov 04, 2019 at 04:10:27PM +0100, Martin Liska wrote:
>>> libsanitizer/ChangeLog:
>>>
>>> 2019-11-05 Martin Liska <mliska@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