This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [google] AddressSanitizer for gcc, first attempt. (issue 5272048)
- From: Diego Novillo <dnovillo at google dot com>
- To: Xinliang David Li <davidxl at google dot com>
- Cc: konstantin dot s dot serebryany at gmail dot com, kcc at google dot com, gcc-patches at gcc dot gnu dot org, reply at codereview dot appspotmail dot com, Richard Guenther <richard dot guenther at gmail dot com>
- Date: Tue, 18 Oct 2011 19:49:40 -0400
- Subject: Re: [google] AddressSanitizer for gcc, first attempt. (issue 5272048)
- References: <20cf300e4f81417e9504af9adae6@google.com> <CAAkRFZJoDHvRhdf80bkenD+Xcsc7-RwUDQ9SGKwh4r6xYN3_EA@mail.gmail.com>
On Tue, Oct 18, 2011 at 19:31, Xinliang David Li <davidxl@google.com> wrote:
> It will be weird to put the instrumentation pass inside loop opt,
> besides memory loads which are loop invariants and redundant stores in
> loop should be handled by pre/pde.
>
> +cc Richard Guenther
>
> You may want to ask the middle-end maintainer to review your code at
> this point if you want it to be in trunk.
For trunk inclusion, we need to decide what to do wrt mudflap.
Clearly, if ASAN offers the same protections and considerable better
performance, then that should be an easy decision.
I still have not looked at the implementation in detail, but I like
the fact that it is a pure gimple pass. If the instrumentation can be
statically optimized, then that is a clear advantage over mudflap,
which we have never been able to optimize properly.
More comments on the patch itself coming soon.
Diego.