[Bug sanitizer/103466] [12 Regression] SIGILL on machine without avx support when using thread sanitizer

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103466 Dmitry Vyukov changed: What|Removed |Added CC||dvyukov at google dot com --- Comment

[Bug sanitizer/90746] __sanitizer_cov_trace_pc should not be tail called

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

[Bug sanitizer/90746] New: __sanitizer_cov_trace_pc should not be tail called

: 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

[Bug sanitizer/85230] asan: false positives in kernel on allocas

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.

[Bug sanitizer/85230] asan: false positives in kernel on allocas

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'

[Bug sanitizer/85230] asan: false positives in kernel on allocas

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:

[Bug sanitizer/85230] asan: false positives in kernel on allocas

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

[Bug sanitizer/85230] asan: false positives in kernel on allocas

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.

[Bug sanitizer/85230] asan: false positives in kernel on allocas

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

[Bug c/85310] optimization ignoring strlen() results

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

[Bug sanitizer/85230] asan: false positives in kernel on allocas

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

[Bug sanitizer/85230] asan: false positives in kernel on allocas

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?

[Bug sanitizer/85230] asan: false positives in kernel on allocas

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

[Bug sanitizer/85230] asan: false positives in kernel on allocas

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

[Bug sanitizer/85230] New: asan: false positives in kernel on allocas

: 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

[Bug sanitizer/82116] "nested bug in the same thread" when a bug is found while reporting another one

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82116 Dmitry Vyukov changed: What|Removed |Added CC||dvyukov at google dot com --- Comment

[Bug target/80148] operand has impossible constraints

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

[Bug inline-asm/80148] operand has impossible constraints

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=edit source code The archive contains slub2.c that works, and slub1.c that fails with the error.

[Bug inline-asm/80148] New: operand has impossible constraints

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

[Bug sanitizer/78158] Strange data race detection with thread sanitizer

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78158 --- Comment #18 from Dmitry Vyukov --- Landed http://llvm.org/viewvc/llvm-project?view=revision=298378 with 0x7fff mask.

[Bug sanitizer/78158] Strange data race detection with thread sanitizer

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.

[Bug sanitizer/78158] Strange data race detection with thread sanitizer

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? :) ---

[Bug sanitizer/78158] Strange data race detection with thread sanitizer

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 === ---

[Bug sanitizer/78158] Strange data race detection with thread sanitizer

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

[Bug sanitizer/78158] Strange data race detection with thread sanitizer

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.

[Bug sanitizer/78158] Strange data race detection with thread sanitizer

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)

[Bug sanitizer/79944] asan: incorrect instrumentation of atomic operations

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!

[Bug sanitizer/79944] asan: incorrect instrumentation of atomic operations

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

[Bug sanitizer/79944] asan: incorrect instrumentation of atomic operations

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=edit reproducer2

[Bug sanitizer/79944] asan: incorrect instrumentation of atomic operations

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

[Bug sanitizer/79944] New: asan: incorrect instrumentation of atomic operations

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

[Bug sanitizer/77538] segmentation fault: thread sanitizer shadow stack overflow

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

[Bug sanitizer/77538] segmentation fault: thread sanitizer shadow stack overflow

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

[Bug sanitizer/78513] [7 Regression] Failure to build linux kernel with KASAN support

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

[Bug middle-end/78294] [5/6/7 Regression] -fsanitize=thread broken by ignoring __attribute__((tls_model("initial-exec")))

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

[Bug middle-end/78294] [5/6/7 Regression] -fsanitize=thread broken by ignoring __attribute__((tls_model("initial-exec")))

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

[Bug middle-end/78294] [5/6/7 Regression] -fsanitize=thread broken by ignoring __attribute__((tls_model("initial-exec")))

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

[Bug middle-end/78294] [5/6/7 Regression] -fsanitize=thread broken by ignoring __attribute__((tls_model("initial-exec")))

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.

[Bug sanitizer/78294] -fsanitize=thread broken

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

[Bug sanitizer/78294] -fsanitize=thread broken

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78294 Dmitry Vyukov changed: What|Removed |Added CC||dvyukov at google dot com --- Comment

[Bug sanitizer/77538] segmentation fault: thread sanitizer shadow stack overflow

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.

[Bug sanitizer/77538] segmentation fault: thread sanitizer shadow stack overflow

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

[Bug sanitizer/77538] segmentation fault: thread sanitizer shadow stack overflow

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?

[Bug sanitizer/78158] Strange data race detection with thread sanitizer

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 If some other non-instrumented library

[Bug sanitizer/78158] Strange data race detection with thread sanitizer

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78158 Dmitry Vyukov changed: What|Removed |Added CC||dvyukov at google dot com --- Comment

[Bug sanitizer/77538] segmentation fault: thread sanitizer shadow stack overflow

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?.

[Bug sanitizer/77538] segmentation fault: thread sanitizer shadow stack overflow

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 []

[Bug sanitizer/77538] segmentation fault: thread sanitizer shadow stack overflow

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

[Bug sanitizer/77538] segmentation fault: thread sanitizer shadow stack overflow

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77538 Dmitry Vyukov changed: What|Removed |Added CC||dvyukov at google dot com --- Comment

[Bug sanitizer/68260] false positive with tsan

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

[Bug sanitizer/68260] false positive with tsan

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

[Bug sanitizer/64354] no preprocessor symbol __SANITIZE_THREAD__

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64354 --- Comment #3 from Dmitry Vyukov --- Thanks!

[Bug sanitizer/71042] libtsan requires __pointer_chk_guard@GLIBC_PRIVATE (6)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71042 Dmitry Vyukov changed: What|Removed |Added CC||dvyukov at google dot com --- Comment

[Bug sanitizer/64354] no preprocessor symbol __SANITIZE_THREAD__

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

[Bug c/69624] sanitize-coverage=trace-pc miscompiles kernel

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

[Bug c/69624] sanitize-coverage=trace-pc miscompiles kernel

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).

[Bug c/69624] sanitize-coverage=trace-pc miscompiles kernel

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69624 --- Comment #17 from Dmitry Vyukov --- Jakub, I guess you can close this. Sorry again.

[Bug c/69624] sanitize-coverage=trace-pc miscompiles kernel

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

[Bug c/69624] sanitize-coverage=trace-pc miscompiles kernel

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,

[Bug sanitizer/68824] [6 Regression] libtsan is missing the __interceptor___tls_get_addr symbol without bumping the soname

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=258119

[Bug sanitizer/68824] [6 Regression] libtsan is missing the __interceptor___tls_get_addr symbol without bumping the soname

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?

[Bug sanitizer/68824] [6 Regression] libtsan is missing the __interceptor___tls_get_addr symbol without bumping the soname

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68824 --- Comment #7 from Dmitry Vyukov --- I will land such fix in clang. Thanks!

[Bug sanitizer/68824] [6 Regression] libtsan is missing the __interceptor___tls_get_addr symbol without bumping the soname

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.

[Bug sanitizer/69204] ThreadSanitizer: False positive on std::promise usage

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

[Bug sanitizer/69204] ThreadSanitizer: False positive on std::promise usage

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

[Bug sanitizer/69204] ThreadSanitizer: False positive on std::promise usage

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69204 Dmitry Vyukov changed: What|Removed |Added CC||dvyukov at google dot com --- Comment

[Bug sanitizer/68824] [6 Regression] libtsan is missing the __interceptor___tls_get_addr symbol without bumping the soname

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68824 Dmitry Vyukov changed: What|Removed |Added CC||dvyukov at google dot com --- Comment

[Bug testsuite/68751] FAIL: gcc.dg/sancov/asan.c (test for excess errors)

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...

[Bug testsuite/68751] FAIL: gcc.dg/sancov/asan.c (test for excess errors)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68751 --- Comment #3 from Dmitry Vyukov --- Committed fix as 231364.

[Bug testsuite/68751] FAIL: gcc.dg/sancov/asan.c (test for excess errors)

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

[Bug sanitizer/68580] FAIL: c-c++-common/tsan/pr65400-1.c -O0 execution test

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68580 Dmitry Vyukov changed: What|Removed |Added CC||dvyukov at google dot com --- Comment

[Bug sanitizer/68338] tsan report error about c++11 static local initialize

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68338 Dmitry Vyukov changed: What|Removed |Added CC||dvyukov at google dot com --- Comment

[Bug sanitizer/68260] false positive with tsan

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68260 Dmitry Vyukov changed: What|Removed |Added CC||dvyukov at google dot com --- Comment

[Bug sanitizer/67575] New: tsan: double instrumentation of x++

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

[Bug sanitizer/67286] asan doen't work on Android(32bit ARM)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67286 --- Comment #4 from Dmitry Vyukov dvyukov at google dot com --- Yes, asan should work on android/arm32. There is some ongoing work on arm64. +eugeni can provide more details.

[Bug sanitizer/67204] documentation for sanitizer missing/incomplete

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67204 Dmitry Vyukov dvyukov at google dot com changed: What|Removed |Added CC||dvyukov

[Bug sanitizer/67009] libsanitizer: shift overflow warnings when boot strapping 32 bit library

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67009 Dmitry Vyukov dvyukov at google dot com changed: What|Removed |Added CC||dvyukov

[Bug sanitizer/61955] libsanitizer fails to compile on RHEL4

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61955 --- Comment #8 from Dmitry Vyukov dvyukov at google dot com --- Kostya, Alexey, Eugeniy, please land this fix to llvm tree while I am OOO.

[Bug sanitizer/61955] libsanitizer fails to compile on RHEL4

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61955 Dmitry Vyukov dvyukov at google dot com changed: What|Removed |Added CC||dvyukov

[Bug sanitizer/63850] Building TSAN for Aarch64 results in assembler Error

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63850 --- Comment #8 from Dmitry Vyukov dvyukov at google dot com --- On Tue, Jan 20, 2015 at 9:06 AM, vekumar at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63850 --- Comment #7 from vekumar at gcc

[Bug sanitizer/63850] Building TSAN for Aarch64 results in assembler Error

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63850 --- Comment #5 from Dmitry Vyukov dvyukov at google dot com --- 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

[Bug sanitizer/59410] tsan tests fail with address randomization disabled

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410 --- Comment #39 from Dmitry Vyukov dvyukov at google dot com --- 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

[Bug sanitizer/59410] tsan tests fail with address randomization disabled

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410 --- Comment #40 from Dmitry Vyukov dvyukov at google dot com --- 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.

[Bug sanitizer/64350] TSAN fails after stress-testing for a while

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64350 Dmitry Vyukov dvyukov at google dot com changed: What|Removed |Added CC||dvyukov

[Bug target/58066] GCC mis-compiles access to TLS variable with -fPIC on x86_64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58066 --- Comment #8 from Dmitry Vyukov dvyukov at google dot com --- 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

[Bug sanitizer/64337] ThreadSanitizer: std::thread + lambda false positive

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64337 Dmitry Vyukov dvyukov at google dot com changed: What|Removed |Added CC||dvyukov

[Bug sanitizer/59302] tsan: Unexpected mmap in InternalAllocator!

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59302 Dmitry Vyukov dvyukov at google dot com changed: What|Removed |Added CC||dvyukov

[Bug sanitizer/59410] tsan tests fail with address randomization disabled

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410 Dmitry Vyukov dvyukov at google dot com changed: What|Removed |Added CC||dvyukov

[Bug sanitizer/64265] [5 Regression] r217669 broke tsan

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64265 Dmitry Vyukov dvyukov at google dot com changed: What|Removed |Added CC||dvyukov

[Bug sanitizer/64265] [5 Regression] r217669 broke tsan

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64265 --- Comment #11 from Dmitry Vyukov dvyukov at google dot com --- 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

[Bug sanitizer/64265] [5 Regression] r217669 broke tsan

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64265 --- Comment #13 from Dmitry Vyukov dvyukov at google dot com --- ... 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

[Bug go/61244] gccgo: ICE in write_specific_type_functions [GoSmith]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61244 --- Comment #2 from Dmitry Vyukov dvyukov at google dot com --- 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

[Bug sanitizer/64265] [5 Regression] r217669 broke tsan

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64265 --- Comment #17 from Dmitry Vyukov dvyukov at google dot com --- 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.

[Bug sanitizer/64265] [5 Regression] r217669 broke tsan

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64265 --- Comment #20 from Dmitry Vyukov dvyukov at google dot com --- No, TSAN_GO is not defined for C/C++ tsan. It's only for race detector for Go language.

[Bug sanitizer/64013] [5 Regression] libsanitizer fails to build

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64013 Dmitry Vyukov dvyukov at google dot com changed: What|Removed |Added CC||dvyukov

[Bug sanitizer/63850] Building TSAN for Aarch64 results in assembler Error

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63850 Dmitry Vyukov dvyukov at google dot com changed: What|Removed |Added CC||dvyukov

[Bug sanitizer/63850] Building TSAN for Aarch64 results in assembler Error

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63850 --- Comment #3 from Dmitry Vyukov dvyukov at google dot com --- 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

[Bug sanitizer/63559] -fsanitize=thread sets no preprocessor flags

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63559 Dmitry Vyukov dvyukov at google dot com changed: What|Removed |Added CC||dvyukov

[Bug sanitizer/63559] -fsanitize=thread sets no preprocessor flags

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63559 --- Comment #3 from Dmitry Vyukov dvyukov at google dot com --- 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.

[Bug libstdc++/62313] Data race in debug iterators

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62313 --- Comment #11 from Dmitry Vyukov dvyukov at google dot com --- 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   2   >