On Thu, 11 May 2023 at 13:42, Jonathan Wakely <jwakely@redhat.com> wrote:

>
>
> On Thu, 11 May 2023 at 13:19, Mike Crowe <mac@mcrowe.com> wrote:
>
>> However, ...
>>
>> > > diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
>> > > index 89e7f5f5f45..e2700b05ec3 100644
>> > > --- a/libstdc++-v3/acinclude.m4
>> > > +++ b/libstdc++-v3/acinclude.m4
>> > > @@ -4284,7 +4284,7 @@
>> AC_DEFUN([GLIBCXX_CHECK_PTHREAD_COND_CLOCKWAIT], [
>> > >        [glibcxx_cv_PTHREAD_COND_CLOCKWAIT=no])
>> > >    ])
>> > >    if test $glibcxx_cv_PTHREAD_COND_CLOCKWAIT = yes; then
>> > > -    AC_DEFINE(_GLIBCXX_USE_PTHREAD_COND_CLOCKWAIT, 1, [Define if
>> > > pthread_cond_clockwait is available in <pthread.h>.])
>> > > +    AC_DEFINE(_GLIBCXX_USE_PTHREAD_COND_CLOCKWAIT,
>> (_GLIBCXX_TSAN==0),
>> > > [Define if pthread_cond_clockwait is available in <pthread.h>.])
>> > >    fi
>>
>> TSan does appear to have an interceptor for pthread_cond_clockwait, even
>> if
>> it lacks the others. Does this mean that this part is unnecessary?
>>
>
> Ah good point, thanks. I grepped for clocklock but not clockwait.
>

In fact it seems like we don't need to change
_GLIBCXX_USE_PTHREAD_RWLOCK_CLOCKLOCK either, because I don't get any tsan
warnings for that. It doesn't have interceptors for
pthread_rwlock_{rd,wr}lock, but it doesn't complain anyway (maybe it's
simply not instrumenting the rwlock functions at all?!)

So I'm now retesting with this version of the patch, which only touches the
USE_PTHREAD_LOCKLOCK macro.

Please take another look, thanks.