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 #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 #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 #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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561
--- Comment #46 from Dmitry Vyukov ---
Roland, why do you think that what you see is false positives? I think these
are real, potentially harmful, races. Please test with gcc 4.9, and file bugs
if you still see any races.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561
--- Comment #49 from Dmitry Vyukov ---
> However, my first idea would be that, since libgomp is not sanitized, not all
> races in 'user land' would be detected. I'm just guessing ...
If libgomp does not access user data (which I suspect it does
Assignee: ian at airs dot com
Reporter: dvyukov at google dot com
$ gccgo -v
Using built-in specs.
COLLECT_GCC=gccgo
COLLECT_LTO_WRAPPER=libexec/gcc/x86_64-unknown-linux-gnu/4.10.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --enable-languages=c,c++,go
Assignee: ian at airs dot com
Reporter: dvyukov at google dot com
$ gccgo -v
Using built-in specs.
COLLECT_GCC=gccgo
COLLECT_LTO_WRAPPER=libexec/gcc/x86_64-unknown-linux-gnu/4.10.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --enable-languages=c,c++,go --disable
Assignee: ian at airs dot com
Reporter: dvyukov at google dot com
Created attachment 32818
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32818&action=edit
reproducer
$ gccgo -v
Using built-in specs.
COLLECT_GCC=gccgo
COLLECT_LTO_WRAPPER=libexec/gcc/x86_64-unknown-linux-gnu/4.1
Assignee: ian at airs dot com
Reporter: dvyukov at google dot com
Created attachment 32824
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32824&action=edit
reproducer
$ gccgo -v
Using built-in specs.
COLLECT_GCC=gccgo
COLLECT_LTO_WRAPPER=libexec/gcc/x86_64-unknow
Assignee: ian at airs dot com
Reporter: dvyukov at google dot com
$ gccgo -v
Using built-in specs.
COLLECT_GCC=gccgo
COLLECT_LTO_WRAPPER=libexec/gcc/x86_64-unknown-linux-gnu/4.10.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --enable-languages=c,c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61246
--- Comment #1 from Dmitry Vyukov ---
Created attachment 32825
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32825&action=edit
reproducer
iority: P3
Component: go
Assignee: ian at airs dot com
Reporter: dvyukov at google dot com
gcc version 4.10.0 20140516 (experimental) (GCC)
Program:
package main
func main() {
var f func(int, interface{})
go f(0, recover())
}
$ go build -compiler=gccgo args.go
args.go:5
FIRMED
Severity: normal
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: dvyukov at google dot com
gcc version 4.10.0 20140516 (experimental) (GCC)
The program is:
package main
func main() {
c := make(chan int)
v := new(int)
b := ne
ty: normal
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: dvyukov at google dot com
gcc version 4.10.0 20140516 (experimental) (GCC)
The program is:
package main
func main() {
((([][]int{})[:])[0])[0]++
}
$ go build -compiler=gccgo /tmp/index
ty: normal
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: dvyukov at google dot com
gcc version 4.10.0 20140516 (experimental) (GCC)
The program is:
package main
func main() {
append([]byte{}, 0)[0]++
}
$ go build -compiler=gccgo src.g
Assignee: ian at airs dot com
Reporter: dvyukov at google dot com
gcc version 4.10.0 20140516 (experimental) (GCC)
The program is:
package main
func main() {
delete(make(map[[0]bool]int), [0]bool{})
}
$ go run -compiler=gccgo crash.go
../../../libgo/runtime/go-map
Component: go
Assignee: ian at airs dot com
Reporter: dvyukov at google dot com
gcc version 4.10.0 20140516 (experimental) (GCC)
The program is:
package main
import "runtime"
import "time"
import "os"
func init() {
runtime.GOMAXPROCS(
Assignee: ian at airs dot com
Reporter: dvyukov at google dot com
Created attachment 32839
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32839&action=edit
reproducer
gcc version 4.10.0 20140516 (experimental) (GCC)
The program is attached.
$ go build -compile
Assignee: ian at airs dot com
Reporter: dvyukov at google dot com
Created attachment 32840
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32840&action=edit
reproducer
gcc version 4.10.0 20140516 (experimental) (GCC)
The reproducer is attached (you need to set GO
Severity: normal
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: dvyukov at google dot com
gccgo (GCC) 4.10.0 20140516 (experimental)
The program is:
package main
func main() {
c := make(chan bool, 1)
for ; false; c <- fa
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: dvyukov at google dot com
CC: cmang at google dot com
Created attachment 32850
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32850&action=edit
reproducer
gcc version
: go
Assignee: ian at airs dot com
Reporter: dvyukov at google dot com
CC: cmang at google dot com
Created attachment 32851
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32851&action=edit
reproducer
gcc version 4.10.0 20140516 (experimental) (GCC
ty: normal
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: dvyukov at google dot com
CC: cmang at google dot com
gcc version 4.10.0 20140516 (experimental) (GCC)
The program is:
package main
func main() {
func() {
NCONFIRMED
Severity: normal
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: dvyukov at google dot com
CC: cmang at google dot com
gcc version 4.10.0 20140516 (experimental) (GCC)
The program is:
package main
func main() {
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=61955
--- Comment #8 from Dmitry Vyukov ---
Kostya, Alexey, Eugeniy, please land this fix to llvm tree while I am OOO.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60055
Dmitry Vyukov changed:
What|Removed |Added
CC||dvyukov at google dot com
--- Comment #3
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=68260
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=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=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=63559
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=63850
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=64013
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=59410
Dmitry Vyukov changed:
What|Removed |Added
CC||dvyukov at google dot com
--- Comment
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=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
--- 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=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 #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=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=64337
Dmitry Vyukov changed:
What|Removed |Added
CC||dvyukov at google dot com
--- Comment
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=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=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=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=61308
--- Comment #2 from Dmitry Vyukov ---
It would be great to accompany these fixes with regression tests. We have
significant amount of Go code in std lib and tests, but still we discover new
code patterns. Any new compiler functionality (like race
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561
--- Comment #53 from Dmitry Vyukov ---
If we instrument libgomp with tsan, this can introduce lots of extraneous
synchronization which is useful only for verification of libgomp itself, but
harmful for libgomp users (as it will lead to false posi
++
Assignee: unassigned at gcc dot gnu.org
Reporter: dvyukov at google dot com
$ g++ -v
gcc version 5.0.0 20140830 (experimental) (GCC)
The program is:
===
#include
#include
#include
std::list::iterator iter, iter2;
void *thread(void *arg)
{
for (int i = 0; i < 100
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62313
--- Comment #2 from Dmitry Vyukov ---
The additional thread only touches iter, and the main thread does not touch
iter nor invalidate it. So there is nothing to protect here. The program does
not contain data races per se.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62313
--- Comment #6 from Dmitry Vyukov ---
> The tests for the debug mode don't generally involve threads, so that isn't
> likely to help.
Then you can run any heavily multithreaded program that extensively uses stl
and is currently race-free. That
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62313
--- Comment #9 from Dmitry Vyukov ---
Don't forget about destructor -- the iterator must be removed from list before
it destruction starts.
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
Created attachment 33486
--> https://gcc.gnu.org/bugzi
-end
Assignee: unassigned at gcc dot gnu.org
Reporter: dvyukov at google dot com
Created attachment 33498
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33498&action=edit
reproducer
gcc version 5.0.0 20140830 (experimental) (GCC)
Build the attached reproducer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63273
--- Comment #2 from Dmitry Vyukov ---
> Which is because to me it's not exactly clear as for what other operations an
atomic load/store is a barrier for.
That's trivial to answer -- memory_order_relaxed is barrier for nothing.
> But eventually
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63273
--- Comment #4 from Dmitry Vyukov ---
For the record, this bug is the result of my attempt to use std atomic
operations in ThreadSanitizer runtime. We do a bunch of relaxed loads and
stores during processing of every memory access in the target p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63273
--- Comment #6 from Dmitry Vyukov ---
The real world situation is:
replace atomic_load/store implementation with relaxed atomic builtins here:
https://gcc.gnu.org/viewcvs/gcc/trunk/libsanitizer/sanitizer_common/sanitizer_atomic_clang_x86.h?view=m
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.
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=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=68751
--- Comment #3 from Dmitry Vyukov ---
Committed fix as 231364.
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=68824
Dmitry Vyukov changed:
What|Removed |Added
CC||dvyukov at google dot com
--- Comment
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=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
--- 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=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=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 #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 #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=67009
Dmitry Vyukov changed:
What|Removed |Added
CC||dvyukov at google dot com
--- Comment
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=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=103466
Dmitry Vyukov changed:
What|Removed |Added
CC||dvyukov at google dot com
--- Comment
101 - 179 of 179 matches
Mail list logo
