-
Notifications
You must be signed in to change notification settings - Fork 17.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cmd/cgo: ThreadSanitizer barks about data races in all.bash #14602
Comments
Unsurprisingly, c8ef0df is the first commit that triggers the failure. |
Do you have clang installed on your system? Which version? |
I don't have clang installed. |
I can confirm this in Linux with commit 686fbdb.
go version devel +686fbdb Thu Mar 3 18:03:45 2016 +0000 linux/amd64
All test passed and new Go binaries installed.
|
@shuLhan Same questions as above: do you have clang installed? What version? If clang is not installed, what version of GCC is installed? Thanks. |
No.
gcc (GCC) 5.3.0 System: Linux xenom-bubu 4.4.3-1-ARCH #1 SMP PREEMPT x86_64 GNU/Linux |
Just a side note, in case someone search and found this issue. If you want to make
Build and test works with clang version 3.7.1. |
I do not have clang installed. My gcc is:
|
I too see this on Ubuntu with gcc 5.3.1 20160320. clang is not installed.
|
@ianlancetaylor I think gcc does not support __has_feature feature used in src/cmd/cgo/out.go. |
@dvyukov I agree that GCC doesn't support __has_feature. As far as I know there is no way in GCC to look at whether some option was passed. I don't see anything in GCC that defines any preprocessor macros to indicate -fsanitize=thread. Do you know if there is any way code compiled by GCC can detect whether -fsanitize=thread was used? |
Gcc provides SANITIZE_ADDRESS, but unfortunately SANITIZE_THREAD is not implemented: What do you think if we look at presence of -fsanitize=thread flag? |
@dvyukov I'm sorry, I don't understand your suggestion of looking at the -fsanitize=thread flag. Right now the test script verifies that the compiler supports -fsanitize=thread. The bug is because people are using a version of GCC that supports that option, but the generated cgo code doesn't detect it, and so the code intended to tell TSAN that there is no race does not run. In the absence of SANITIZE_THREAD I don't see a way to fix this. I think we have to change the test to not run when using GCC. But if you have a better idea I would like to understand it. |
I meant the following: |
Another idea: Enable race support when It will work automatically with clang, but gcc users will need to use -fsanitize=thread -D__SANITIZE_THREAD. Eventually gcc will define the macro internally. |
Joining the 'bug report', even though most of the problem has been identified. TL;DR
Longer version
Do you want me to open up a separate issue for the new error? Or is it related to this one? |
The second one looks like a different bug to me. This one is about threadsanitizer failing when clang is not present, the one you see is triggered by |
CL https://golang.org/cl/22688 mentions this issue. |
go version devel +b83f397 Wed Mar 2 19:32:41 2016 +0000 linux/amd64
I'm seeing this on tip:
The text was updated successfully, but these errors were encountered: