http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309
--- Comment #6 from Kostya Serebryany 2013-02-05
09:21:59 UTC ---
I am slightly confused. Are we discussing compile time or test-run-time?
I've just built SPEC 2006 with -fsanitize=address -O2
gcc: r195706
clang: r174324
Measured on Int
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309
--- Comment #7 from Kostya Serebryany 2013-02-05
09:43:11 UTC ---
If we are talking about compile time, I observe 2x difference in favor of
clang:
building 483.xalancbmk
gcc+asan+O2: 564 seconds
clang+asan+O2: 243 second
gcc is bui
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309
--- Comment #9 from Kostya Serebryany 2013-02-05
10:30:16 UTC ---
> And, for compile time, you want to be testing with --enable-checking=release
Thanks!
With --enable-checking=release gcc's compile time drops to 374 seconds.
That's much
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309
--- Comment #10 from Kostya Serebryany 2013-02-05
10:41:20 UTC ---
(In reply to comment #8)
> "464.h264ref with gcc loops forever, I did not investigate why."
> is PR53073 , you can use -fno-aggressive-loop-optimizations to workaround the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309
--- Comment #15 from Kostya Serebryany 2013-02-05
12:22:56 UTC ---
Well, I of course can change the SPEC code
464.h264ref, 1271.00,1879.00,1.47
As for Dodji's patch: can someone attach it here?
Let me benc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309
--- Comment #17 from Kostya Serebryany 2013-02-06
11:18:28 UTC ---
Trying this patch:
% cat inc.cc
void foo(int *a) {
(*a)++;
}
% gcc -fsanitize=address -O2 inc.cc -S -o - | grep __asan_report
call__asan_report_load4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309
--- Comment #18 from Kostya Serebryany 2013-02-06
12:24:51 UTC ---
First results with the patch (c-only tests, train data):
orig patched
401.bzip2,89.60,90.10, 1.01
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309
--- Comment #20 from Kostya Serebryany 2013-02-06
12:43:09 UTC ---
> The clang variant looks incorrect to me - if asan distinguishes between
> loads and stores
It doesn't.
The only reason why we have two callbacks is that asan
prints a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309
--- Comment #23 from Kostya Serebryany 2013-02-07
05:01:53 UTC ---
with the patch from comment 22 (all benchmarks, ref data):
orig patched
400.perlbench,-1.00, 1244.00, -1244.00
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309
--- Comment #26 from Kostya Serebryany 2013-02-08
06:31:26 UTC ---
FTR: here is the perf data for zero-based offset (clang)
https://code.google.com/p/address-sanitizer/wiki/ZeroBasedShadow#Performance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309
--- Comment #28 from Kostya Serebryany 2013-02-08
09:13:27 UTC ---
> Could we on x86_64 think about mem_to_shadow(x) (x >> 3) + 0x7fff8000 (note,
> not |, but +)?
That sounds compelling, but I afraid we may have binaries with 2G of
text
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56245
--- Comment #8 from Kostya Serebryany 2013-02-08
18:28:43 UTC ---
Ah, so this *is* caused by the asan merge, although it's not an asan bug.
The new asan allocator often returns pointers that are >4Gb apart from
each other so that int is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56128
--- Comment #9 from Kostya Serebryany 2013-02-11
11:54:46 UTC ---
(In reply to comment #8)
> Requires a merge as far as I can see. Important enough build issue.
I am reluctant to do another full merge so close to 4.8 -- we have too many
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56128
--- Comment #11 from Kostya Serebryany 2013-02-11
12:58:07 UTC ---
> We need more than that. E.g. ppc64 asan is very much broken in the gcc tree,
> that is fixed in upstream libasan already, right?
Last time I tried, basic tests passed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309
--- Comment #30 from Kostya Serebryany 2013-02-11
14:42:43 UTC ---
> Could we on x86_64 think about mem_to_shadow(x) (x >> 3) + 0x7fff8000
Committed http://llvm.org/viewvc/llvm-project?rev=174886&view=rev
which adds an optional flag -mll
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309
--- Comment #32 from Kostya Serebryany 2013-02-12
06:47:56 UTC ---
Good news, 0x7fff8000 seems great:
t0: orig
t1: short offset (0x7fff8000)
t2: zero offset + pie
t0 t1 t1/t0 t2t2/t0 t2/t1
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309
--- Comment #33 from Kostya Serebryany 2013-02-12
07:02:40 UTC ---
(In reply to comment #31)
> If the mapping is so flexible, how can you detect mismatches? Different scale
> or shadow offsets are ABI incompatible...
We don't detect mism
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309
--- Comment #36 from Kostya Serebryany 2013-02-12
08:58:56 UTC ---
> I see, but then you could use the global vars (perhaps weak ones in libasan
> with some default), combined together with arguments to __asan_init (or some
> alternative n
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309
--- Comment #37 from Kostya Serebryany 2013-02-12
11:17:45 UTC ---
http://llvm.org/viewvc/llvm-project?rev=174957&view=rev (and r174958)
change the default offset for x86_64 to 7fff8000
and changes __asan_init to __asan_init_v1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309
Kostya Serebryany changed:
What|Removed |Added
CC||glider at google dot com
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56128
Kostya Serebryany changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56393
--- Comment #3 from Kostya Serebryany 2013-02-19
14:11:32 UTC ---
Looks like __asan_init is not called early enough.
To confirm, run
ASAN_OPTIONS=verbosity=1 ./a.out
if __asan_init is called it should print something like this:
==
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56393
Kostya Serebryany changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56393
--- Comment #8 from Kostya Serebryany 2013-02-20
14:30:16 UTC ---
With http://llvm.org/viewvc/llvm-project?rev=175623&view=rev
__asan_init is called from preinit_array, thus fixing this problem.
Will try to merge to gcc in a few days.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56393
--- Comment #10 from Kostya Serebryany 2013-02-20
14:49:20 UTC ---
(In reply to comment #9)
> .preinit_array is only processed in executables, so this only affects
> -static-libasan,
Right. This is the only mode officially supported by
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56393
--- Comment #15 from Kostya Serebryany 2013-02-21
11:35:51 UTC ---
r196201 landed the fresh asan run-time into gcc.
-static-libasan should work well now, please try.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56393
--- Comment #19 from Kostya Serebryany 2013-02-22
07:01:51 UTC ---
In clang, static asan-rt is the default and the only option on Linux.
(On Mac, the only option is dynamic, but that's a quite unfortunate limitation
of the platform, it c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309
--- Comment #43 from Kostya Serebryany 2013-02-22
07:11:06 UTC ---
gcc r196201: -O2 -fno-aggressive-loop-optimizations
clang 175735: -O2
x86_64 linux, both are using the new 7fff8000 shadow offset
400.perlbench, 1136.00,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309
--- Comment #45 from Kostya Serebryany 2013-02-22
08:36:14 UTC ---
> I'm wondering if the failure goes away compiled with -O0 instead ?
No, the failure is still present with -O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309
--- Comment #47 from Kostya Serebryany 2013-02-22
13:52:12 UTC ---
(In reply to comment #46)
> (In reply to comment #43)
> > 400.perlbench fails with a global-buffer-overflow which clang does not
> > detect.
> > I did not investigate why
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56425
Bug #: 56425
Summary: debug info is broken with -fsanitize=address
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309
--- Comment #49 from Kostya Serebryany 2013-02-22
14:29:27 UTC ---
with -gdwarf-3:
==11621== ERROR: AddressSanitizer: global-buffer-overflow on address
0x0078e2a5 at pc 0x4e47d7 bp 0x7fff553d4cc0 sp 0x7fff553d4cb8
READ of size 1 at 0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56425
--- Comment #1 from Kostya Serebryany 2013-02-22
14:29:57 UTC ---
clarification: -gdwarf-3 seems to work, but -g is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56425
--- Comment #3 from Kostya Serebryany 2013-02-22
14:37:06 UTC ---
ah yea, sorry. I use vanilla addr2line from ubuntu 12.04
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309
--- Comment #50 from Kostya Serebryany 2013-02-22
14:54:24 UTC ---
reproducer:
#include
#include
int foo(const char *x, const char *y, int len) {
return memcmp(x, y, len);
}
int main() {
printf("%d\n", foo("perlio", "unix", 6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309
--- Comment #53 from Kostya Serebryany 2013-02-22
15:06:25 UTC ---
The interceptor we have is conservative:
INTERCEPTOR(int, memcmp, const void *a1, const void *a2, uptr size) {
if (!asan_inited) return internal_memcmp(a1, a2, size);
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56454
Bug #: 56454
Summary: need to rename attribute no_address_safety_analysis to
no_sanitize_address
Classification: Unclassified
Product: gcc
Version: unknown
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56454
--- Comment #2 from Kostya Serebryany 2013-02-26
07:19:00 UTC ---
Long story short:
we needed to unify the names for asan/tsan/msan attributes.
Now they are called
no_sanitize_address
no_sanitize_thread
no_sanitize_memory
Lengthy d
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56454
--- Comment #5 from Kostya Serebryany 2013-02-26
07:38:42 UTC ---
Hm... Ok...
Although there is a risk that this way we may never reach a decision.
Is there a precedent of solving issues this way?
How about __has_feature, by the way?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309
--- Comment #56 from Kostya Serebryany 2013-02-26
07:43:19 UTC ---
http://llvm.org/viewvc/llvm-project?rev=176078&view=rev
makes memcmp interceptor more aggressive, so that clang finds this bug
in perlbmk too.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56454
--- Comment #7 from Kostya Serebryany 2013-02-26
08:07:16 UTC ---
Your comment #6 explains why I did not CC gcc lists to the clang discussion. :)
There are too many strong opinions on both sides and I don't want to
be an instigator of a h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56454
--- Comment #9 from Kostya Serebryany 2013-02-26
08:46:36 UTC ---
Clang accepts the old name silently.
I am not sure about "forever",
clang will probably start printing a "deprecated" warning at some point.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309
--- Comment #57 from Kostya Serebryany 2013-02-28
11:31:54 UTC ---
I've created a page that describes how I run SPEC with asan.
There is also a patch that works around the known SPEC bugs.
https://code.google.com/p/address-sanitizer/wik
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56454
--- Comment #11 from Kostya Serebryany 2013-02-28
12:01:34 UTC ---
Created attachment 29550
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29550
rename no_address_safety_analysis to no_sanitize_address
How do we decide? When is the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56454
--- Comment #13 from Kostya Serebryany 2013-02-28
12:36:12 UTC ---
> This doesn't DTRT with the old attribute, because you lookup_attribute only
> the
> new name.
> Either you'd need to look up also the old name, or
> handle_no_address_s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56393
--- Comment #23 from Kostya Serebryany 2013-04-08
06:32:45 UTC ---
(In reply to comment #22)
> Has this been resolved in the final 4.8.0 (r196952)? I checked some changes
> and
> they seems to be in.
>
> I have a number (<100) C++/C pa
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316
--- Comment #1 from Kostya Serebryany ---
Feel free to patch this in 4.8 branch directly.
As for the trunk, please send the patches to the upstream (LLVM) repo first.
Sorry for the breakages, but we are unable to monitor build failures on old
ke
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55517
--- Comment #9 from Kostya Serebryany ---
> I'd like to try ASAN on a system where the sysadmins enforce
> a hard limit. Is this possible?
No. asan requires 20Tb (+ a bit) of *virtual* memory to properly function.
talk to your sysadmins to rela
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55517
--- Comment #11 from Kostya Serebryany ---
> That will not happen. So ASAN will be unusable for me unless
> it can be changed to work with a sane amount of virtual memory.
Correct.
I don't know any way to make ASAN work in the presence of hard V
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56393
--- Comment #26 from Kostya Serebryany ---
(In reply to David Abdurachmanov from comment #25)
> I downloaded GCC 4.8.1 (final) and binutils 2.23.1 (default ld.gold). The
> problem is that boost and a lot other C/C++ packages are not compiled w/
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57507
--- Comment #1 from Kostya Serebryany ---
FTR: we don't yet officially support C++11 treads, so this is quite expected.
Patches and tests (to the upstream repo) are welcome
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316
--- Comment #6 from Kostya Serebryany ---
> Would a fallback implementation of BlockingMutex::{Lock,Unlock}() that uses
> pthread_mutex_*() be sensible here?
That would be non-trivial. We intercept the pthread_ functions so we can't
call them di
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kcc at gcc dot gnu.org
For some reason, g++ (r202164) generates a call to an incorrect DTOR,
but never generates the DTOR itself. As the result, we get this link error:
undefined reference to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58201
--- Comment #4 from Kostya Serebryany ---
Nice. Any hope?
Chromium is another project which we can't build with gcc trunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58294
Kostya Serebryany changed:
What|Removed |Added
CC||kcc at gcc dot gnu.org
--- Comment
: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: kcc at gcc dot gnu.org
Created attachment 30774
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30774&action=edit
z.cc
Fresh gcc trunk r202241, Linux x86_64
% $GCC_TR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58465
--- Comment #2 from Kostya Serebryany ---
does this happen with clang trunk?
BTW, I hope to do a fresh merge in the nearest 2-3 weeks.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58465
--- Comment #6 from Kostya Serebryany ---
Is that the full stack trace?
(As usual, a reproducer will help us much)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58465
--- Comment #10 from Kostya Serebryany ---
Your stack traces tells me this:
__sanitizer::MmapOrDie calls strerror, which means that mmap call failed.
This may happen if the process OOM-ed (unlikely in your case),
or may have some kind of limit (
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58465
--- Comment #12 from Kostya Serebryany ---
You can also try
ASAN_OPTIONS=malloc_context_size=1 (or 0)
this will eliminate this particular call to mmap (but will reduce the
usefulness
of asan report)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58465
--- Comment #8 from Kostya Serebryany ---
ouch!
free calling malloc. this is not going to work :)
This code has changed since our last merge to gcc --
the trunk version does not have strerror call any more.
I really hope to make another merge
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58680
Kostya Serebryany changed:
What|Removed |Added
CC||eugeni.stepanov at gmail dot
com,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58718
--- Comment #4 from Kostya Serebryany ---
I am currently testing a merge which is before Alexey's changes.
There is no harm in keeping this bug open.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55517
--- Comment #13 from Kostya Serebryany ---
(In reply to m...@gcc.gnu.org from comment #12)
> This is annoying as it causes a large amount of chaff in the gcc/g++
> testsuite runs if one has not previously done a ulimit -v unlimited.
Patches (upst
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58718
--- Comment #6 from Kostya Serebryany ---
Can we keep this bug in one place, please?
Let https://code.google.com/p/address-sanitizer/issues/detail?id=239 be the
primary one
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59018
--- Comment #1 from Kostya Serebryany ---
At least one of these patches does not build with clang:
/home/kcc/llvm/projects/compiler-rt/lib/sanitizer_common/sanitizer_linux.cc:807:21:
error: ignored asm label 'r8' on automatic variable [-Werror]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59018
--- Comment #4 from Kostya Serebryany ---
the patches look good and pass our testing on x86_64 and i386.
Thanks!
committed as http://llvm.org/viewvc/llvm-project?view=revision&revision=194155
(fixed 4 small lint warnings there)
We have few opti
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59018
--- Comment #5 from Kostya Serebryany ---
> Can you try
>
> register void *r8 __asm__ ("r8") = newtls;
> register int *r10 __asm__ ("r10") = child_tidptr;
Yep, works!
> But you need to enable x32 first on your OS, which requires
>
> 1. x3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59018
--- Comment #8 from Kostya Serebryany ---
>> I will submit my patches to GCC now.
Ok!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #1 from Kostya Serebryany ---
It should be there already:
http://gcc.gnu.org/viewcvs?rev=204368&root=gcc&view=rev
Please check.
admittedly, the gcc tree lacks the tests for lsan.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #3 from Kostya Serebryany ---
https://code.google.com/p/address-sanitizer/wiki/LeakSanitizer
I agree, we need to update the gcc doc to mention the URL above.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #5 from Kostya Serebryany ---
(In reply to Joost VandeVondele from comment #4)
> That's great... works even for Fortran code :-)
Wow!
>
> One more question the docs mention:
>
> In performance-critical scenarios, LSan can also be u
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58937
--- Comment #6 from Kostya Serebryany ---
adding attribute ctor to __asan_init is questionable
- windows has different syntax.
- running non-instrumented binary w/o calling __asan_init at startup is risky:
the binary may call memset/etc an touch s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59009
--- Comment #5 from Kostya Serebryany ---
So far we were not even able to reproduce it.
As I told in another thread, please apply any minimal #ifdef patch to
sanitizer_platform_limits_linux.cc to make it compile (while keeping tests
running on x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59009
--- Comment #7 from Kostya Serebryany ---
Is this fixed by http://gcc.gnu.org/viewcvs?rev=204726&root=gcc&view=rev ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55353
Kostya Serebryany changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59106
--- Comment #2 from Kostya Serebryany ---
We should be building libsanitizer with -fno-rtti
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59106
--- Comment #5 from Kostya Serebryany ---
a small part of ubsan does indeed require rtti.
See ubsan/CMakeLists.txt (UBSAN_SOURCES vs UBSAN_CXX_SOURCES)
The rest of libsanitizer does not and should use -fno-rtti.
OMG, I hate having so many diffe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59106
--- Comment #7 from Kostya Serebryany ---
Patch looks ok.
Please send it in a usual way and someone else (Jakub?) will need to approve
it.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59106
Kostya Serebryany changed:
What|Removed |Added
CC||nlewycky at google dot com
--- Commen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59009
--- Comment #13 from Kostya Serebryany ---
No objections, thanks!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #7 from Kostya Serebryany ---
> > Clang supports -fsanitize=leak which simply links a standalone lsan library
> > (no instrumentation at compile time required).
> > Perhaps gcc can add such option too.
>
> I agree that such an optio
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #9 from Kostya Serebryany ---
(In reply to Joost VandeVondele from comment #8)
> (In reply to Kostya Serebryany from comment #7)
> > -fno-omit-frame-pointer: that may or may not be a good idea, I don't know.
>
> I seem to need it to g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #11 from Kostya Serebryany ---
> > I am not an expert in the gcc build system so this will have to be done by
> > someone else. Also, I am heavily frightened by the amount of differences
> > between the clang and gcc builds of libsan
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
Kostya Serebryany changed:
What|Removed |Added
CC||samsonov at google dot com
--- Commen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #18 from Kostya Serebryany ---
(In reply to Joost VandeVondele from comment #17)
> (In reply to Sergey Matveev from comment #16)
> >
> > Under the current behavior -fsanitize=address,leak is equivalent to
> > -fsanitize=address.
> >
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #20 from Kostya Serebryany ---
> I our simulation code, it looks like the overhead for leak checking is about
> 20%. I haven't done very careful measurements yet, since this is more or
> less what we're willing to pay to integrate the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #22 from Kostya Serebryany ---
(In reply to Joost VandeVondele from comment #21)
> (In reply to Kostya Serebryany from comment #20)
> > > I our simulation code, it looks like the overhead for leak checking is
> > > about
> > > 20%. I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59136
Kostya Serebryany changed:
What|Removed |Added
CC||glider at google dot com,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994
--- Comment #21 from Kostya Serebryany ---
Author: kcc
Date: Fri Nov 15 10:31:14 2013
New Revision: 204838
URL: http://gcc.gnu.org/viewcvs?rev=204838&root=gcc&view=rev
Log:
fix PR sanitizer/58994
Modified:
trunk/libsanitizer/ChangeLog
tr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59106
--- Comment #11 from Kostya Serebryany ---
Trying to build chrome with gcc's asan...
The build barks as in this bug -- we do need to build libsanitizer (at least
asan) with -fno-rtti
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59106
--- Comment #13 from Kostya Serebryany ---
> Did it work with the patch?
Yes!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #25 from Kostya Serebryany ---
(In reply to Jakub Jelinek from comment #24)
> Just tried to bootstrap/regtest that patch, unfortunately it doesn't build
> at all on i686. Is it meant to work on x86_64 only (or only for
> SANITIZER_WOR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59106
--- Comment #15 from Kostya Serebryany ---
(In reply to Yury Gribov from comment #14)
> Sent to gcc-patches: http://gcc.gnu.org/ml/gcc-patches/2013-11/msg01990.html
>
> As for libubsan, it does not seem to support static link anyway:
you need -l
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59188
--- Comment #1 from Kostya Serebryany ---
Interesting. tsan in clang works, so we either have problems in the
gcc build system or we have some differences in the code that affect the
sigsetjmp interceptor.
one other problem would be that we ha
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59215
--- Comment #1 from Kostya Serebryany ---
This reminds me http://llvm.org/bugs/show_bug.cgi?id=17066
Do you have this problem with clang's tsan?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59215
--- Comment #3 from Kostya Serebryany ---
> I can try to come up with a minimal test case... Yet, I cannot imagine
> that the following would ever work with TSan:
> typedef int _Atomic_word;
It does not matter how _Atomic_word is de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59215
--- Comment #8 from Kostya Serebryany ---
(In reply to Jonathan Wakely from comment #6)
> I realise that, but the general point is still valid: for race detectors to
> understand the atomic updates in the library they library needs to be
> compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59215
--- Comment #5 from Kostya Serebryany ---
> > But only if you re-compile stdlibc++ with tsan,
>
> It's libstdc++ not stdlibc++, I don't know why everyone gets that wrong :-)
Sorry (I usually get it right) :)
>
> Anyway, this is already docum
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59215
--- Comment #11 from Kostya Serebryany ---
> _Atomic_word __count = _M_use_count; < the read
Interesting.
We haven't seen these (we don't use this implementation of shared_ptr).
I think the code is simply wrong -- it
1 - 100 of 294 matches
Mail list logo
