This is the mail archive of the
mailing list for the GCC project.
Re: Experimental Address Sanitizer for 4.8 (was Re: How much time left till phase 3?)
It would be nice to have a complete tsan/asan implementation for 4.8
-- IMHO it is one of the major missing (popular) features in gcc, so
the earlier gcc has it the better.
Killing mudlap is a completely different goal which does not have to
be tied to this release.
The question is that since asan/tsan is not enabled by default and its
development won't destablize GCC, is it OK to allow more asan/tsan
related changes to be checked in to 4.8 after stage-1 is closed. They
can be considered as 'bug' fixes.
On Fri, Oct 5, 2012 at 8:59 AM, Dodji Seketeli <email@example.com> wrote:
> Diego Novillo <firstname.lastname@example.org> writes:
>> On 2012-10-02 05:45 , Richard Guenther wrote:
>>> Anybody else with things they want to merge during stage1?
>> Finally, I've been thinking of porting asan/tsan to replace
>> mudflap. Dodji, you expressed interest in it recently.
> Yes I did. A bit too recently, I am afraid. :-)
> Jeff Law <email@example.com> writes:
>> On 10/02/2012 08:30 AM, Diego Novillo wrote:
>>> Finally, I've been thinking of porting asan/tsan to replace mudflap.
>>> Dodji, you expressed interest in it recently.
>> That's further out most likely.
> Yes, I think a *final* version with feature parity with the asan/tsan of
> llvm is definitely for after 4.8. Though ...
> Jakub Jelinek <firstname.lastname@example.org> writes:
>> I think it would be very nice to get at least asan port for 4.8, but
>> I guess it depends on how much work is on it. Killing mudflap would be
> ... I'd like to try and see if we can have something dubbed experimental
> with very basic functionality into 4.8 first, and then work from there
> toward feature parity with asan/tsan llvm.
> What do you think?