http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #16 from Sergey Matveev ---
(In reply to Kostya Serebryany from comment #11)
> > Easily doable of course, but we should create liblsan as shared
> > library in that case too. What combination of those do you allow? I mean,
> > is
> >
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #31 from Sergey Matveev ---
(In reply to Kostya Serebryany from comment #30)
> lsan's allocator clears all memory using internal_memset, which is damn
> slow. (sets on byte at a time)
>
> asan's allocator doesn't do that (it sets firs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #33 from Sergey Matveev ---
(In reply to Kostya Serebryany from comment #32)
> > I think standalone LSan should support the max_alloc_fill_size flag.
>
> Mmm. Maybe...
> max_alloc_fill_size in asan is there primarily to protect from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #37 from Sergey Matveev ---
I've patched LSan to use the real memset(). At least on my machine this brought
no performance improvement compared to kcc's latest change (just FYI - not
trying to make any point).
As of now, LSan will sti
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #38 from Sergey Matveev ---
(In reply to Jakub Jelinek from comment #28)
> Author: jakub
> Date: Fri Nov 22 21:13:08 2013
> New Revision: 205290
It looks like you use dynamic linking by default. The last time I checked, leak
detection
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: earthdok at google dot com
CC: jakub at gcc dot gnu.org, kcc at gcc dot gnu.org,
samsonov at google dot com
In GCC trunk, if -nostdlib/-nodefaultlibs is passed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65639
--- Comment #2 from Sergey Matveev ---
This is also discussed in the email thread following the clang commit:
https://www.mail-archive.com/cfe-commits@cs.uiuc.edu/msg106622.html
You could say that by passing -fsanitize=address at link time, we e
