http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55517
--- Comment #7 from kcc at gcc dot gnu.org 2012-11-28 13:17:21 UTC ---
BTW, the messages are actually quite nice:
==22487== ERROR: Failed to allocate 0x2001000 (2199023259648) bytes at
address 0x0000 (12)
==22487
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55485
--- Comment #7 from Kostya Serebryany kcc at gcc dot gnu.org 2012-11-28
13:37:02 UTC ---
Note that the LLVM implementation inserts a call to __asan_handle_no_return
before every no-return call instruction.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55485
--- Comment #9 from Kostya Serebryany kcc at gcc dot gnu.org 2012-11-28
14:00:53 UTC ---
Correct.
__asan_handle_no_return may loose some of the stack-buffer overflows.
It is also used to handle clone case, where the entire stack should
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561
--- Comment #4 from Kostya Serebryany kcc at gcc dot gnu.org 2012-12-02
10:28:10 UTC ---
Note that tsan currently requires to use -pie linker flag (and either -fPIC or
-fPIE compiler flag).
Obviously, your failure happens before the run
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55599
--- Comment #4 from Kostya Serebryany kcc at gcc dot gnu.org 2012-12-05
04:01:41 UTC ---
the interpose thing can not be linked statically, afaict.
So, let's just drop -static-libasan from darwin.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55599
--- Comment #6 from Kostya Serebryany kcc at gcc dot gnu.org 2012-12-05
06:10:31 UTC ---
note that in LLVM the static runtime library is still the default one,
because it's now the one that simply works
But once we switch to interpose
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341
Kostya Serebryany kcc at gcc dot gnu.org changed:
What|Removed |Added
CC||kcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341
--- Comment #10 from Kostya Serebryany kcc at gcc dot gnu.org 2012-12-10
13:20:51 UTC ---
./a.out | python ./asan_symbolize.py
It should be
./a.out 21 | python ./asan_symbolize.py
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341
--- Comment #12 from Kostya Serebryany kcc at gcc dot gnu.org 2012-12-10
13:28:12 UTC ---
Does pure addr2line work?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55410
Kostya Serebryany kcc at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341
--- Comment #17 from Kostya Serebryany kcc at gcc dot gnu.org 2012-12-19
08:37:21 UTC ---
For whatever reason the fortran code is touching asan's shadow:
Address 0x16742e2c is located in the high shadow area.
What
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341
--- Comment #20 from Kostya Serebryany kcc at gcc dot gnu.org 2012-12-19
08:51:54 UTC ---
For whatever reason the fortran code is touching asan's shadow:
Address 0x16742e2c is located in the high shadow area.
What
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341
--- Comment #25 from Kostya Serebryany kcc at gcc dot gnu.org 2012-12-19
10:32:29 UTC ---
So, to fix this, either libasan should for memset ignore any diagnostics for
stores into shadow memory area,
That's not a good choice. I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341
--- Comment #27 from Kostya Serebryany kcc at gcc dot gnu.org 2012-12-19
14:29:12 UTC ---
This time it looks like a valid error report (stack buffer overflow), but asan
crashes while reporting it.
Take a look at DescribeAddressIfStack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341
--- Comment #41 from Kostya Serebryany kcc at gcc dot gnu.org 2012-12-21
08:11:19 UTC ---
Wild guess: does Fortran have any custom unwinding mechanism (like exceptions
in C++ or longjmp in C)?
For C/C++ we've spent quite some time to get
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341
--- Comment #43 from Kostya Serebryany kcc at gcc dot gnu.org 2012-12-21
08:23:09 UTC ---
false stack-buffer-overflow reports may appear if you have stack unwinding
*somewhere*, not necessary in this routine.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55739
--- Comment #5 from Kostya Serebryany kcc at gcc dot gnu.org 2012-12-21
09:46:41 UTC ---
Just for the record:
llvm implementation of asan does not catch these either for the same reason.
It would be interesting to find a way to implement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341
--- Comment #45 from Kostya Serebryany kcc at gcc dot gnu.org 2012-12-23
07:44:32 UTC ---
The point of failure is not in the object,
but in a routine called after a routine from this object finishes.
What if you remove -fsanitize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55844
--- Comment #3 from Kostya Serebryany kcc at gcc dot gnu.org 2013-01-02
17:31:05 UTC ---
we should just move over to using the dwarf unwinder and forget about the
manually unwinding the stack
Upstream asan-rt has two flags now
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55844
--- Comment #5 from Kostya Serebryany kcc at gcc dot gnu.org 2013-01-03
06:17:38 UTC ---
Could you please do an extra merge soon, even before switching the default?
I'll start somewhere after Jan 10.
(I am on holidays before
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55938
Kostya Serebryany kcc at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55488
Kostya Serebryany kcc at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
--- Comment #1 from Kostya Serebryany kcc at gcc dot gnu.org 2013-01-15
06:12:27 UTC ---
[DISCLAIMER] I don't have access nor any experience with powerpc.
Could you please insert various debugging Printf calls before the assertion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55989
--- Comment #1 from Kostya Serebryany kcc at gcc dot gnu.org 2013-01-15
08:49:42 UTC ---
Will the following patch work?
Index: sanitizer_common/sanitizer_linux.cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55989
--- Comment #3 from Kostya Serebryany kcc at gcc dot gnu.org 2013-01-15
09:04:35 UTC ---
False return from these functions will not negatively impact GCC at run time
No change in libsanitizer can affect GCC at run time unless you
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
Kostya Serebryany kcc at gcc dot gnu.org changed:
What|Removed |Added
CC||bergner
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
--- Comment #4 from Kostya Serebryany kcc at gcc dot gnu.org 2013-01-16
10:14:03 UTC ---
Btw, the mapping I see on my PPC linux box ends with 0x1000
(with ASLR off)
ffd-1000 rw-p 00:00 0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
Kostya Serebryany kcc at gcc dot gnu.org changed:
What|Removed |Added
Summary|FAIL: |asan
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
--- Comment #8 from Kostya Serebryany kcc at gcc dot gnu.org 2013-01-16
11:54:36 UTC ---
Sounds good for both.
Andreas, could you please try replacing
kHighMemEnd = 0x0fffUL
with
kHighMemEnd = 0x3fffUL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
--- Comment #10 from Kostya Serebryany kcc at gcc dot gnu.org 2013-01-17
08:30:05 UTC ---
Since I can't reproduce the failure,
please help me debug this (basically, print all local variables around the
assertion and the proc maps
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
--- Comment #14 from Kostya Serebryany kcc at gcc dot gnu.org 2013-01-18
08:26:00 UTC ---
Because of this:
#define kLowShadowBeg SHADOW_OFFSET
#define kLowShadowEnd MEM_TO_SHADOW(kLowMemEnd)
If we leave kLowShadowEnd as before, we
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
--- Comment #15 from Kostya Serebryany kcc at gcc dot gnu.org 2013-01-18
11:40:57 UTC ---
There are two off-by-one:
In LLVM trunk: http://llvm.org/viewvc/llvm-project?rev=172807view=rev
Initially I wanted to do a merge to gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
--- Comment #16 from Kostya Serebryany kcc at gcc dot gnu.org 2013-01-18
12:30:11 UTC ---
-#define SHADOW_OFFSET (1ULL 41)
+#define SHADOW_OFFSET (1ULL 43)
On my ppc box which uses 44 bit address space this does not work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
--- Comment #21 from Kostya Serebryany kcc at gcc dot gnu.org 2013-01-18
15:33:33 UTC ---
While we are at it...
It is possible to use zero shadow offset of powerpc somehow?
on x86_64 linux, when I build the code with -fPIC -pie
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
--- Comment #23 from Kostya Serebryany kcc at gcc dot gnu.org 2013-01-18
15:46:00 UTC ---
in our use-case 5% of run-time (and code size too) is a lot.
We are currently in the process of migrating the chrome builds to zero based
offset
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
--- Comment #24 from Kostya Serebryany kcc at gcc dot gnu.org 2013-01-21
09:11:22 UTC ---
I've tried adding the offset instead of OR-ing it and got 2%-5% slowdown and
same code size increase on SPEC on x86_64 (using fresh clang -02).
So
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
--- Comment #25 from Kostya Serebryany kcc at gcc dot gnu.org 2013-01-23
12:21:51 UTC ---
So, what is our decision?
Are we just doing
- static const uptr kHighMemEnd = 0x0fffUL;
+ static const uptr kHighMemEnd
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
--- Comment #27 from Kostya Serebryany kcc at gcc dot gnu.org 2013-01-23
12:51:40 UTC ---
BTW, I wonder why clang generates larger and slower code with ADD instead of
OR
I did not investigate. I noticed that the code size
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
--- Comment #29 from Kostya Serebryany kcc at gcc dot gnu.org 2013-01-23
13:19:30 UTC ---
Why doesn't it error for unlimited stack say on x86_64?
Because on x86_64 the stack is still high enough (we are lucky).
Note: I would
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
--- Comment #31 from Kostya Serebryany kcc at gcc dot gnu.org 2013-01-23
13:32:11 UTC ---
I've committed an upstream change
http://llvm.org/viewvc/llvm-project?view=revrevision=173260 that makes
kHighMemEnd dynamic.
Hopefully
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
--- Comment #34 from Kostya Serebryany kcc at gcc dot gnu.org 2013-01-23
13:50:31 UTC ---
Do you really want to make kHighMemEnd dynamic always? Shouldn't it be
dynamic
only when needed (i.e. for configurations like ppc64 which now
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
--- Comment #36 from Kostya Serebryany kcc at gcc dot gnu.org 2013-01-24
07:19:00 UTC ---
Well, although the ppc64 LNT bot is not quite functional yet, there are many
of
us who run the LLVM unit test suite several times a day. So
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
--- Comment #38 from Kostya Serebryany kcc at gcc dot gnu.org 2013-01-24
13:46:17 UTC ---
OK. Please let me know if we can assist setting up a PPC bot in the future,
to
help maintain compatibility.
Oh, that'll be great even now
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55374
--- Comment #17 from Kostya Serebryany kcc at gcc dot gnu.org 2013-01-29
09:10:24 UTC ---
Note that there is at least one known bug in asan with -static-libstdc++
https://code.google.com/p/address-sanitizer/issues/detail?id=147
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55374
--- Comment #19 from Kostya Serebryany kcc at gcc dot gnu.org 2013-01-29
09:18:49 UTC ---
As with the patch for this PR -lasan is linked before -lstdc++, the wrapper
should kick in. But the patch is still unreviewed.
How?
If we
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55374
--- Comment #21 from Kostya Serebryany kcc at gcc dot gnu.org 2013-01-29
09:44:22 UTC ---
we could similarly error for
-static-libstdc++ -fsanitize=address combination.
Maybe.
Generally this works (in clang at least) and no one
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56128
--- Comment #4 from Kostya Serebryany kcc at gcc dot gnu.org 2013-01-30
06:43:51 UTC ---
I'd prefer to simply disable libsanitizer build if something is not supported.
Since we are not testing it on older kernels, many things may be broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55617
--- Comment #18 from Kostya Serebryany kcc at gcc dot gnu.org 2013-01-30
16:36:01 UTC ---
Yea... We don't have interest in supporting gcc-asan-darwin, sorry.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309
--- Comment #6 from Kostya Serebryany kcc at gcc dot gnu.org 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309
--- Comment #7 from Kostya Serebryany kcc at gcc dot gnu.org 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309
--- Comment #9 from Kostya Serebryany kcc at gcc dot gnu.org 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309
--- Comment #10 from Kostya Serebryany kcc at gcc dot gnu.org 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309
--- Comment #15 from Kostya Serebryany kcc at gcc dot gnu.org 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309
--- Comment #17 from Kostya Serebryany kcc at gcc dot gnu.org 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309
--- Comment #18 from Kostya Serebryany kcc at gcc dot gnu.org 2013-02-06
12:24:51 UTC ---
First results with the patch (c-only tests, train data):
orig patched
401.bzip2,89.60
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309
--- Comment #20 from Kostya Serebryany kcc at gcc dot gnu.org 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58680
Kostya Serebryany kcc at gcc dot gnu.org changed:
What|Removed |Added
CC||eugeni.stepanov
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58718
--- Comment #4 from Kostya Serebryany kcc at gcc dot gnu.org ---
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 kcc at gcc dot gnu.org ---
(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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58718
--- Comment #6 from Kostya Serebryany kcc at gcc dot gnu.org ---
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 kcc at gcc dot gnu.org ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59018
--- Comment #4 from Kostya Serebryany kcc at gcc dot gnu.org ---
the patches look good and pass our testing on x86_64 and i386.
Thanks!
committed as http://llvm.org/viewvc/llvm-project?view=revisionrevision=194155
(fixed 4 small lint warnings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59018
--- Comment #5 from Kostya Serebryany kcc at gcc dot gnu.org ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59018
--- Comment #8 from Kostya Serebryany kcc at gcc dot gnu.org ---
I will submit my patches to GCC now.
Ok!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #1 from Kostya Serebryany kcc at gcc dot gnu.org ---
It should be there already:
http://gcc.gnu.org/viewcvs?rev=204368root=gccview=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 kcc at gcc dot gnu.org ---
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 kcc at gcc dot gnu.org ---
(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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58937
--- Comment #6 from Kostya Serebryany kcc at gcc dot gnu.org ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59009
--- Comment #5 from Kostya Serebryany kcc at gcc dot gnu.org ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59009
--- Comment #7 from Kostya Serebryany kcc at gcc dot gnu.org ---
Is this fixed by http://gcc.gnu.org/viewcvs?rev=204726root=gccview=rev ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55353
Kostya Serebryany kcc at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59106
--- Comment #2 from Kostya Serebryany kcc at gcc dot gnu.org ---
We should be building libsanitizer with -fno-rtti
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59106
--- Comment #5 from Kostya Serebryany kcc at gcc dot gnu.org ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59106
--- Comment #7 from Kostya Serebryany kcc at gcc dot gnu.org ---
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 kcc at gcc dot gnu.org changed:
What|Removed |Added
CC||nlewycky
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59009
--- Comment #13 from Kostya Serebryany kcc at gcc dot gnu.org ---
No objections, thanks!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #7 from Kostya Serebryany kcc at gcc dot gnu.org ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #9 from Kostya Serebryany kcc at gcc dot gnu.org ---
(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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #11 from Kostya Serebryany kcc at gcc dot gnu.org ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
Kostya Serebryany kcc at gcc dot gnu.org changed:
What|Removed |Added
CC||samsonov
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #18 from Kostya Serebryany kcc at gcc dot gnu.org ---
(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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #20 from Kostya Serebryany kcc at gcc dot gnu.org ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #22 from Kostya Serebryany kcc at gcc dot gnu.org ---
(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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59136
Kostya Serebryany kcc at gcc dot gnu.org changed:
What|Removed |Added
CC||glider
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994
--- Comment #21 from Kostya Serebryany kcc at gcc dot gnu.org ---
Author: kcc
Date: Fri Nov 15 10:31:14 2013
New Revision: 204838
URL: http://gcc.gnu.org/viewcvs?rev=204838root=gccview=rev
Log:
fix PR sanitizer/58994
Modified:
trunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59106
--- Comment #11 from Kostya Serebryany kcc at gcc dot gnu.org ---
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 kcc at gcc dot gnu.org ---
Did it work with the patch?
Yes!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #25 from Kostya Serebryany kcc at gcc dot gnu.org ---
(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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59106
--- Comment #15 from Kostya Serebryany kcc at gcc dot gnu.org ---
(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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59188
--- Comment #1 from Kostya Serebryany kcc at gcc dot gnu.org ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59215
--- Comment #1 from Kostya Serebryany kcc at gcc dot gnu.org ---
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 kcc at gcc dot gnu.org ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59215
--- Comment #8 from Kostya Serebryany kcc at gcc dot gnu.org ---
(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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59215
--- Comment #5 from Kostya Serebryany kcc at gcc dot gnu.org ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59215
--- Comment #11 from Kostya Serebryany kcc at gcc dot gnu.org ---
_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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59215
--- Comment #13 from Kostya Serebryany kcc at gcc dot gnu.org ---
(In reply to Oleg Smolsky from comment #12)
Hey Kostya, should I try suppressing the report using the function name?
Would it work in optimized builds that have inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59215
--- Comment #15 from Kostya Serebryany kcc at gcc dot gnu.org ---
(In reply to Joost VandeVondele from comment #14)
(In reply to Jonathan Wakely from comment #10)
No, you're right, that's a different issue. I think we've just been relying
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59063
--- Comment #20 from Kostya Serebryany kcc at gcc dot gnu.org ---
This is fixed in llvm trunk, right?
I am planing another merge to gcc in ~1 week.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59188
--- Comment #11 from Kostya Serebryany kcc at gcc dot gnu.org ---
planing next merge from llvm to gcc in ~1 week.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #30 from Kostya Serebryany kcc at gcc dot gnu.org ---
(In reply to Joost VandeVondele from comment #29)
I've tried -fsanitize=leak and it works well, thanks!
Concerning the speed, I'm still seeing about 20% slowdown (again
1 - 100 of 293 matches
Mail list logo
