https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103466
Dmitry Vyukov changed:
What|Removed |Added
CC||dvyukov at google dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90746
--- Comment #3 from Dmitry Vyukov ---
> It would probably useful to have __attribute__((notailcall)) which the
> sanitizers then could stick on the function types.
It should be on _declaration_, right? Sanitizers only provide a definition. The
: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: dvyukov at google dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85230
--- Comment #21 from Dmitry Vyukov ---
I guess it just used my system binutils. Used to work before.
I now used an older distribution to build it. Seems to work.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85230
--- Comment #19 from Dmitry Vyukov ---
When I am trying to build anything with -g on a machine with binutils 2.26.1 I
am getting:
/tmp/ccTFsPnM.s: Assembler messages:
/tmp/ccTFsPnM.s:11: Error: unknown .loc sub-directive `view'
/tmp/ccTFsPnM.s:1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85230
--- Comment #16 from Dmitry Vyukov ---
Here is disasm of the function with the patch:
https://gist.githubusercontent.com/dvyukov/e9dca961ceb436049cf5881b3307b104/raw/05ed3daff60d00eb71ca7a85be707d6d5eca3c47/gistfile1.txt
And the epilogue:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85230
--- Comment #12 from Dmitry Vyukov ---
When/if you have a patch I can test it on kernel.
But seems this is a problem for user-space too. We just need a large alloca +
signal handlers, or dirty manual SP manipulations (like we have in tsan to
imp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85230
--- Comment #8 from Dmitry Vyukov ---
Depending on how long the proper fix will take. If we are talking about, say, a
week then I will just wait. We have to deal with hundreds of assorted kernel
crashes all over the place anyway.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85230
--- Comment #6 from Dmitry Vyukov ---
Right!
Unpoisoning before restoring SP looks like a reasonable and simple solution to
me. I don't see any potential downsides.
Do you mind submitting a fix for this?
Thanks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85310
--- Comment #6 from Dmitry Vyukov ---
It seems to me that compiler is fine here and we just have a bug in kernel
code.
Result of strlen called on char[16] can't possibly by >15 (without causing
undefined behavior -- reading past the end of the ob
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85230
--- Comment #4 from Dmitry Vyukov ---
Removing these lines from runtime does not help unfortunately:
- kasan_poison_shadow(left_redzone, KASAN_ALLOCA_REDZONE_SIZE,
- KASAN_ALLOCA_LEFT);
The right redzone is also someho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85230
--- Comment #3 from Dmitry Vyukov ---
Hummm, perhaps gcc expects that the left ASAN redzone will be within the
128-byte ABI redzone, but this becomes false with -mno-red-zone?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85230
--- Comment #2 from Dmitry Vyukov ---
The runtime callbacks look correct to me, and the shadow they produce also
looks reasonable: 32-byte rezone before, 32 + (32 - object size) redzone after:
8800247b7180: 00 00 00 00 00 00 00 00 00 00 00
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85230
--- Comment #1 from Dmitry Vyukov ---
I am also looking at kernel callback implementation, maybe they disagree with
compiler as to what's actually passed as arguments:
/* Emitted by compiler to poison alloca()ed objects. */
void __asan_alloca_p
: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: dvyukov at google dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
We
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82116
Dmitry Vyukov changed:
What|Removed |Added
CC||dvyukov at google dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80148
--- Comment #3 from Dmitry Vyukov ---
> Why doesn't the kernel use atomic builtins instead?
There was a recent discussion here:
https://groups.google.com/forum/#!topic/kasan-dev/3sNHjjb4GCI
In short:
---
Trivially, The C++ model doesn't feature
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80148
--- Comment #1 from Dmitry Vyukov ---
Created attachment 41016
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41016&action=edit
source code
The archive contains slub2.c that works, and slub1.c that fails with the error.
Assignee: unassigned at gcc dot gnu.org
Reporter: dvyukov at google dot com
Target Milestone: ---
This pop up in kernel code. We have:
#define __cmpxchg_double(pfx, p1, p2, o1, o2, n1, n2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78158
--- Comment #18 from Dmitry Vyukov ---
Landed http://llvm.org/viewvc/llvm-project?view=revision&revision=298378 with
0x7fff mask.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78158
--- Comment #16 from Dmitry Vyukov ---
Yeah, but before introduction of HLE there were no special flags, and one did
not need to filter at all. And before the sync flag there were no
special-special flags, and one only need to filter 0x. What
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78158
--- Comment #14 from Dmitry Vyukov ---
Right, we need to catch completely bogus values.
But the question is: are these values extending up or down? :)
Because special flag was added after the HLE flags...
So how about 12 bits? :)
--- lib/tsan/r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78158
--- Comment #12 from Dmitry Vyukov ---
I want to land something along the following lines (with proper comments).
Any objections?
Index: tsan_interface_atomic.cc
===
--- tsan_interf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78158
--- Comment #8 from Dmitry Vyukov ---
We need to modify tsan runtime to ignore (zero) __ATOMIC_HLE_ACQUIRE/RELEASE
bits, right? It's only an optimization and we can pretend that elision never
succeeds under tsan.
What is sync special bit (0x4000
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78158
--- Comment #5 from Dmitry Vyukov ---
I may be missing something, but can't we just always emit calls into tsan
runtime under tsan? They accept the memory order value and can work with
constants and runtime values.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78158
--- Comment #3 from Dmitry Vyukov ---
Also reported on stackoverflow:
http://stackoverflow.com/questions/37552866/why-does-threadsanitizer-report-a-race-with-this-lock-free-example
I've checked with
gcc version 7.0.1 20170307 (experimental) (GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79944
--- Comment #6 from Dmitry Vyukov ---
Just build kernel with it. Boots fine and sustains some load now.
Did not do any positive tests, though.
Thanks for the quick fix!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79944
--- Comment #4 from Dmitry Vyukov ---
Attached second minimized reproducer.
Build it with:
gcc dmaengine2.c -fsanitize=address -O2 -lasan -g
It produces:
==57662==ERROR: AddressSanitizer: unknown-crash on address 0x00601321 at pc
0x0040
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79944
--- Comment #3 from Dmitry Vyukov ---
Created attachment 40918
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40918&action=edit
reproducer2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79944
--- Comment #2 from Dmitry Vyukov ---
I've shutup that bug with dest = NULL, but then I immediately got this:
BUG: KASAN: global-out-of-bounds in clear_bit
include/linux/bitops_compiler.h:15 [inline]
BUG: KASAN: global-out-of-bounds in dma_chann
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: dvyukov at google dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
Target Milestone: ---
Created attachment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77538
--- Comment #23 from Dmitry Vyukov ---
Please provide disassembly of the function that contains the PC
(__gnu_cxx::__normal_iterator...).
Did we fix any bugs that lead to missed __tsan_func_exit callbacks?
Before we go any deeper, I would sugges
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77538
--- Comment #21 from Dmitry Vyukov ---
> is that huge number abnormal?
Let's say it is atypical for C/C++ programs because of fixed-size stacks. But
tsan has limit of 64K frames in the latest version (maybe 4.8.2 had limit of
32K frames).
But do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78513
--- Comment #6 from Dmitry Vyukov ---
> Then GCC 7 won't build any kernel with KASAN until those kernel patches go in?
Yes.
Kernel passes -fsanitize=kernel-address, some behavior tuning can be done based
on that flag.
Please notify kasan-...@g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78294
--- Comment #26 from Dmitry Vyukov ---
> I was under the impression that upstream wouldn't be interested in this patch,
because llvm uses static compiler-rt libs and clang doesn't run into this
issue.
Upstream is not interested from this point o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78294
--- Comment #25 from Dmitry Vyukov ---
> The question is if we want to change this or not and in what way.
I would say that we need to change something, because current behavior is
counter-intuitive.
In tsan runtime we have a declaration with t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78294
--- Comment #23 from Dmitry Vyukov ---
Markus,
Changes to sanitizer runtimes are not committed into gcc tree. The upstream is
in llvm tree. Changes must go there first, then they are backported to gcc
tree. Your change will be overwritten on nex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78294
--- Comment #16 from Dmitry Vyukov ---
So is it a bug in gcc or in tsan runtime?
I thought that an attribute attached to a definition must affect declaration as
well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78294
--- Comment #5 from Dmitry Vyukov ---
Markus, how do you configure and build gcc? Is there anything special?
Our tls accesses should not go through __tls_get_addr because we use
initial-exec attribute. __tls_get_addr vs indirect access through g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78294
Dmitry Vyukov changed:
What|Removed |Added
CC||dvyukov at google dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77538
--- Comment #18 from Dmitry Vyukov ---
Looks like shadow stack overflow.
Do you use fibers, ucontext, longjmp, exceptions or any other non-obvious
control flow constructs?
Fibers and exceptions are not supported. Longjmp should work.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77538
--- Comment #16 from Dmitry Vyukov ---
> The stack size limit in my box is 8M. I have also checked /proc/limits.
So, is increasing stack size help?
Tsan increases stack consumption. 8MB is not that much provided that you have
1MB frames.
> By e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77538
--- Comment #12 from Dmitry Vyukov ---
The crash in gdb looks like stack overflow (unsurprising if there are 1MB
frames). Does increasing thread stack size or reducing frame size (there must
something very big on the stack) help?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78158
--- Comment #2 from Dmitry Vyukov ---
With -O0 there is huge potential for ODR violations. E.g. code contains:
401774: e8 f3 06 00 00 callq 401e6c
::operator bool() const>
If some other non-instrumented library contains a non-in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78158
Dmitry Vyukov changed:
What|Removed |Added
CC||dvyukov at google dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77538
--- Comment #9 from Dmitry Vyukov ---
Humm... what are they waiting for? Is it also core dump? Stack for the sleeping
task is missing for some reason.
What kernel version do you use? Maybe the problem is with the kernel? Isn't it
too old?.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77538
--- Comment #6 from Dmitry Vyukov ---
It hangs trying to dump core file to some pipe:
[] pipe_wait+0x70/0xc0
[] pipe_write+0x236/0x5b0
[] do_sync_write+0x8d/0xd0
[] dump_write+0x52/0x70
[] dump_seek+0xa4/0xe0
[] elf_core_dump+0x896/0x950
[] do_c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77538
--- Comment #4 from Dmitry Vyukov ---
Unkillable processed in D state usually mean kernel bugs (and there are lots of
them: https://github.com/google/syzkaller/wiki/Found-Bugs).
Please post results of 'cat /proc/PID/task/*/stack` and `cat
/proc/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77538
Dmitry Vyukov changed:
What|Removed |Added
CC||dvyukov at google dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68260
--- Comment #7 from Dmitry Vyukov ---
I looked at the patch, but I am unqualified to review it. The test looks good
to me. +Yuri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68260
--- Comment #4 from Dmitry Vyukov ---
Good point. I wonder if using -O2 fixes this.
We tend to always use tsan with -O2 for performance reasons. Tsan already
considerably slows down execution, and additional unnecessary memory accesses
and non-in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64354
--- Comment #3 from Dmitry Vyukov ---
Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71042
Dmitry Vyukov changed:
What|Removed |Added
CC||dvyukov at google dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64354
--- Comment #1 from Dmitry Vyukov ---
We've hit this issue while implementing Go support for C++ ThreadSanitizer:
https://github.com/golang/go/issues/14602
__has_feature obviously does not work. Providing __SANITIZE_THREAD__ looks very
reasonable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69624
--- Comment #17 from Dmitry Vyukov ---
Jakub, I guess you can close this.
Sorry again.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69624
--- Comment #16 from Dmitry Vyukov ---
> Could you please push that to the syzkaller tree [1] then?
Sorry, syzkaller page referred to outdated patch. I was hoping that Andrew will
take it soon, so that I can update the link to a more respected l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69624
--- Comment #14 from Dmitry Vyukov ---
Wait, I already disabled instrumentation of hweight.c for because of this:
+# Kernel does not boot if we instrument this file as it uses custom calling
+# convention (see CONFIG_ARCH_HWEIGHT_CFLAGS).
+KCOV_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69624
--- Comment #8 from Dmitry Vyukov ---
First of all, are you sure that r12 is not 0 before the call?
Deference of 0xdc00 is how KASAN reacts on NULL deref, it does
shadow check before the memory accesses. If original address is NULL,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69624
--- Comment #6 from Dmitry Vyukov ---
Also what gcc version?
I've tried:
gcc version 6.0.0 20160105 (experimental) (GCC)
$ gcc /tmp/af_netlink.c -c -O2 -fsanitize-coverage=trace-pc
-fsanitize=kernel-address --param asan-stack=1 --param asan-glo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68824
--- Comment #10 from Dmitry Vyukov ---
Submitted in:
http://llvm.org/viewvc/llvm-project?view=revision&revision=258119
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68824
--- Comment #8 from Dmitry Vyukov ---
Jakub, does the following patch look good to you?
Just don't want to intermix tsan and sanitizer_common interceptor macros.
I think it's better to define and initialize an interceptor in a single file.
Inde
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68824
--- Comment #7 from Dmitry Vyukov ---
I will land such fix in clang. Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68824
--- Comment #5 from Dmitry Vyukov ---
In 3) did you mean -mstackrealign?
1) looks like the simplest option. Are there any downsides?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69204
--- Comment #11 from Dmitry Vyukov ---
> No it just exposes the problem of using futex system calls with TSAN.
What is that problem?
Future does not use futex for synchronization, only for wait optimization. So I
don't see how it can cause false
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69204
--- Comment #6 from Dmitry Vyukov ---
The problem is that gcc does not instrument atomic operations for some reason.
Here is disasm of future::set_result:
Dump of assembler code for function
std::__future_base::_State_baseV2::_M_set_result(std:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69204
Dmitry Vyukov changed:
What|Removed |Added
CC||dvyukov at google dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68824
Dmitry Vyukov changed:
What|Removed |Added
CC||dvyukov at google dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68751
--- Comment #4 from Dmitry Vyukov ---
Do I have rights to change status? Can't find how to close this...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68751
--- Comment #3 from Dmitry Vyukov ---
Committed fix as 231364.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68751
--- Comment #2 from Dmitry Vyukov ---
Mailed a fix yesterday:
https://gcc.gnu.org/ml/gcc-patches/2015-12/msg00671.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68580
Dmitry Vyukov changed:
What|Removed |Added
CC||dvyukov at google dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68338
Dmitry Vyukov changed:
What|Removed |Added
CC||dvyukov at google dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68260
Dmitry Vyukov changed:
What|Removed |Added
CC||dvyukov at google dot com
--- Comment
Assignee: unassigned at gcc dot gnu.org
Reporter: dvyukov at google dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
Target Milestone: ---
This come up during work on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67286
--- Comment #4 from Dmitry Vyukov ---
Yes, asan should work on android/arm32. There is some ongoing work on arm64.
+eugeni can provide more details.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67204
Dmitry Vyukov changed:
What|Removed |Added
CC||dvyukov at google dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67009
Dmitry Vyukov changed:
What|Removed |Added
CC||dvyukov at google dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61955
--- Comment #8 from Dmitry Vyukov ---
Kostya, Alexey, Eugeniy, please land this fix to llvm tree while I am OOO.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61955
Dmitry Vyukov changed:
What|Removed |Added
CC||dvyukov at google dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63850
--- Comment #8 from Dmitry Vyukov ---
On Tue, Jan 20, 2015 at 9:06 AM, vekumar at gcc dot gnu.org
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63850
>
> --- Comment #7 from vekumar at gcc dot gnu.org ---
> (In reply to clyon from commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63850
--- Comment #5 from Dmitry Vyukov ---
I suspect that configure and Makefiles are gcc-specific, that is needs to be
submitted to gcc diredctly.
And for tsan_rtl.h we have a change in flight that does essentially the same
(for mips64 support):
http
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
--- Comment #40 from Dmitry Vyukov ---
Phil, please move the discussion to:
https://groups.google.com/forum/#!forum/thread-sanitizer
This is not gcc specific, and more people will be able to see it in the tsan
group.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
--- Comment #39 from Dmitry Vyukov ---
>Isomalloc works best when we can assure it as large a range of common,
>unoccupied virtual address space as possible. Thus, it's much happier when
>ASLR is disabled.
I do not follow you here. How does AS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58066
--- Comment #8 from Dmitry Vyukov ---
Is there any progress on this? Is it fixed?
I've hit this issue in ThreadSanitizer. It intercepts __tls_get_addr and then
code that uses MOVDQA [rbp] crashes. I remember that I hit it previously in
some othe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64350
Dmitry Vyukov changed:
What|Removed |Added
CC||dvyukov at google dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64337
Dmitry Vyukov changed:
What|Removed |Added
CC||dvyukov at google dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64265
--- Comment #20 from Dmitry Vyukov ---
No, TSAN_GO is not defined for C/C++ tsan. It's only for race detector for Go
language.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64265
--- Comment #17 from Dmitry Vyukov ---
Great.
Jakub, then you can go for gcc support whenever you have time. It's not super
priority as we managed to live without exceptions support so far.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61244
--- Comment #2 from Dmitry Vyukov ---
Chris, when you fix these, please also add tests to the main Go repo. These are
code patterns that we never saw before. Collections of these patterns will be a
great asset for regression testing and any futur
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64265
--- Comment #13 from Dmitry Vyukov ---
> ... we actually don't want any __tsan_func_{entry,exit} calls if there are no
> memory accesses in the function...
... and no calls to other functions, because these functions can contain memory
accesses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64265
--- Comment #11 from Dmitry Vyukov ---
>Doing it in gimplify_function_tree is pretty straightforward
That's good!
>So, the question is just if you want to do it that way...
Kostya, can you say anything about llvm? On the tsan issue you said:
"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64265
Dmitry Vyukov changed:
What|Removed |Added
CC||dvyukov at google dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
Dmitry Vyukov changed:
What|Removed |Added
CC||dvyukov at google dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59302
Dmitry Vyukov changed:
What|Removed |Added
CC||dvyukov at google dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64013
Dmitry Vyukov changed:
What|Removed |Added
CC||dvyukov at google dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63850
--- Comment #3 from Dmitry Vyukov ---
Sure, you can do local experimentation in gcc.
Yes, gcc Makefile will need to be updated as well.
But I am more concerned about shadow memory layout. Tsan mapping is somewhat
different from asan.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63850
Dmitry Vyukov changed:
What|Removed |Added
CC||dvyukov at google dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63559
--- Comment #3 from Dmitry Vyukov ---
Ah, OK, thanks.
FWIW, TBB is open-source. However it uses hand-rolled atomic operations, so
tsan won't work out-of-the box anyway.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63559
Dmitry Vyukov changed:
What|Removed |Added
CC||dvyukov at google dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62313
--- Comment #11 from Dmitry Vyukov ---
Just test it with
g++ test.cc -Wall -lpthread -fsanitize=thread -pie -fPIE -D_GLIBCXX_DEBUG -g
-O2
There is nothing else I can do on top of that.
1 - 100 of 179 matches
Mail list logo
