This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
RE: [PING] [PATCH] Fix parameters of __tsan_vptr_update
- From: Bernd Edlinger <bernd dot edlinger at hotmail dot de>
- To: Dmitry Vyukov <dvyukov at google dot com>
- Cc: Konstantin Serebryany <konstantin dot s dot serebryany at gmail dot com>, Mike Stump <mikestump at comcast dot net>, Kostya Serebryany <kcc at google dot com>, Jakub Jelinek <jakub at redhat dot com>, Richard Biener <richard dot guenther at gmail dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 21 Jan 2015 10:59:06 +0100
- Subject: RE: [PING] [PATCH] Fix parameters of __tsan_vptr_update
- Authentication-results: sourceware.org; auth=none
- References: <DUB118-W36BD6269214D3EE6E26A4AE4510 at phx dot gbl> <20150102190102 dot GB1667 at tucnak dot redhat dot com>,<DUB118-W157955758BEE04CBCE299FE45D0 at phx dot gbl> <20150102212901 dot GG1667 at tucnak dot redhat dot com>,<DUB118-W23B6AF5E187BC7CE6646AEE45D0 at phx dot gbl> <DUB118-W23B4CFAA5A198B57689EBDE45B0 at phx dot gbl>,<DUB118-W16B4004988A5B0A3EE2CC2E4420 at phx dot gbl> <DUB118-W519443EF06A1C4DB96059EE44F0 at phx dot gbl>,<CACT4Y+YBJRzG9c4KSrykO5NbaGeAKfmJUTb7ryqk4dX_Hx5aNQ at mail dot gmail dot com>,<DUB118-W2875D28C15EDA755AEEC50E44F0 at phx dot gbl> <CACT4Y+a3j84+Pgp4zfuh2vRdDK3dy1WqA3oOMqhzWs+mQ5mqWg at mail dot gmail dot com>,<B45A3E4F-8313-45BE-946A-B0C159FF9120 at comcast dot net> <CAGQ9bdxAVfod2cQUz2YQLxH9F1ovVkaqXC1qSO5JPfA9jPvWGg at mail dot gmail dot com>,<DUB118-W32DE3E55FB0ADCB62D2790E44B0 at phx dot gbl>,<CACT4Y+Z4jndiYsHuyjc6dGqtYLtrBLOpHZtniCU9TDuax-u4pQ at mail dot gmail dot com>
Hi,
On Wed, 21 Jan 2015 12:58:27, Dmitry Vyukov wrote:
>
>
> The step approach looks better to me at first sight.
>
> Busy waiting looks like a weak argument in this context. It's
> absolutely non performance-critical and a yield or usleep(10) will
> solve it more than sufficiently.
>
> I will check how complex to make its implementation invisible to tsan
> (I suspect that clang does not ignore atomic operations when
> no_sanitize_thread attribute is given) and whether it actually makes
> more complex tests simpler to write (as compared to the barrier
> approach).
Yes, for Gcc this is a pretty new feature, so I dont think we should use it now.
It _should_ suppress the instrumentation of atomics, but it can not be used to
avoid intercepted calls like usleep, and using sched_yield is safe, but usleep
is intercepted, and may change the printed diagnostics.
But unfortunately it is not really stable at the time:
cat test.c
volatile int serial=0;
__attribute__((no_sanitize_thread))
void step (int i)
{
while (__atomic_load_n (&serial, __ATOMIC_ACQUIRE) != i - 1)
sched_yield();
__atomic_store_n (&serial, i, __ATOMIC_RELEASE);
}
gcc -S -fsanitize=thread test.c
test.c: In function 'step':
test.c:6:6: warning: implicit declaration of function 'sched_yield' [-Wimplicit-function-declaration]
sched_yield();
^
test.c:3:6: internal compiler error: in expand_TSAN_FUNC_EXIT, at internal-fn.c:243
void step (int i)
^
0x966b17 expand_TSAN_FUNC_EXIT
../../gcc-5-20150118/gcc/internal-fn.c:243
0x75438f expand_call_stmt
../../gcc-5-20150118/gcc/cfgexpand.c:2311
0x75438f expand_gimple_stmt_1
../../gcc-5-20150118/gcc/cfgexpand.c:3327
0x75438f expand_gimple_stmt
../../gcc-5-20150118/gcc/cfgexpand.c:3481
0x75a862 expand_gimple_basic_block
../../gcc-5-20150118/gcc/cfgexpand.c:5394
0x75c087 execute
../../gcc-5-20150118/gcc/cfgexpand.c:6003
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
Bernd.