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. thanks, David On Fri, Oct 5, 2012 at 8:59 AM, Dodji Seketeli <do...@redhat.com> wrote: > Diego Novillo <dnovi...@google.com> 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 <l...@redhat.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 <ja...@redhat.com> 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 >> nice. > > ... 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? > > -- > Dodji
