https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78158
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78158
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment #21
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78158
--- Comment #20 from Jakub Jelinek ---
Author: jakub
Date: Wed Mar 22 18:46:54 2017
New Revision: 246402
URL: https://gcc.gnu.org/viewcvs?rev=246402&root=gcc&view=rev
Log:
PR sanitizer/78158
* tsan/tsan_interface_atomic.cc: Cherr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78158
--- Comment #19 from torvald at gcc dot gnu.org ---
(In reply to Dmitry Vyukov from comment #8)
> 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
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 #17 from Jakub Jelinek ---
It is hard to predict. That said, I think libtsan uses mostly the old style
__sync_* intrinsics or when it uses atomic_load/store it uses them with memory
model not known at compile time, therefore it acts
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 #15 from Jakub Jelinek ---
For target HLE-like flags that are optimizations only it should grow up, the
sync flag is really a very special beast, so it has been intentionally added
into the low 16 bits.
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 #13 from Jakub Jelinek ---
& 0x7fff would make more sense (the sync special bit is actually 0x8000 rather
than what I wrote), but guess for now even & 7 will work.
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 #11 from Jakub Jelinek ---
Fixed on the trunk so far.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78158
--- Comment #10 from Jakub Jelinek ---
Author: jakub
Date: Tue Mar 21 08:22:57 2017
New Revision: 246306
URL: https://gcc.gnu.org/viewcvs?rev=246306&root=gcc&view=rev
Log:
PR sanitizer/78158
* tsan.c (instrument_builtin_call): If
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78158
Jakub Jelinek changed:
What|Removed |Added
CC||torvald at gcc dot gnu.org
--- Comment #
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 #7 from Jakub Jelinek ---
Or the sync special bit (0x4000)?
That said,
if (!tree_fits_uhwi_p (last_arg)
|| memmodel_base (tree_to_uhwi (last_arg)) >= MEMMODEL_LAST)
actually just ignores the higher bits (al
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78158
--- Comment #6 from Jakub Jelinek ---
Does it support e.g.
__ATOMIC_HLE_ACQUIRE (1 << 16) and
__ATOMIC_HLE_RELEASE (1 << 17) bits ored into the memory model?
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
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78158
--- Comment #4 from Jakub Jelinek ---
That is clearly due to bugs in tsan.c, in my PR55439 r194133 changes.
At -O0 the code is not optimized, so we end up with e.g.
__m_6 = 5;
__b_7 = std::operator& (__m_6, 65535);
__m.10_8 = (int) __m_6;
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=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 #1
23 matches
Mail list logo
