This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix sporadic failure in g++.dg/tsan/aligned_vs_unaligned_race.C
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Mike Stump <mikestump at comcast dot net>
- Cc: Bernd Edlinger <bernd dot edlinger at hotmail dot de>, "H.J. Lu" <hjl dot tools at gmail dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, Dmitry Vyukov <dvyukov at google dot com>
- Date: Thu, 8 Jan 2015 20:29:16 +0100
- Subject: Re: [PATCH] Fix sporadic failure in g++.dg/tsan/aligned_vs_unaligned_race.C
- Authentication-results: sourceware.org; auth=none
- References: <DUB118-W1417B0F343893BD17318BAE4590 at phx dot gbl> <A5E27EC0-33BE-4043-8B5E-07394E68AE41 at comcast dot net> <DUB118-W189C82F5D792A3B997EED5E4460 at phx dot gbl> <20150107082339 dot GN1667 at tucnak dot redhat dot com> <887DE6D6-D1D2-4432-B6F8-D55707BA2387 at comcast dot net> <20150107170027 dot GV1667 at tucnak dot redhat dot com> <DUB118-W3640B7ADB7473323625ED2E4460 at phx dot gbl> <20150107183216 dot GW1667 at tucnak dot redhat dot com> <DUB118-W50B35996E4A58F0727A81CE4460 at phx dot gbl> <6E94E5C6-78C3-41E8-9B1B-ADF20347412B at comcast dot net>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Thu, Jan 08, 2015 at 11:24:21AM -0800, Mike Stump wrote:
> On Jan 7, 2015, at 2:44 PM, Bernd Edlinger <bernd.edlinger@hotmail.de> wrote:
> > Here is a new patch, that uses this method on all tsan tests,
> > which seem to depend on sleep(1), and which have unstable results
> > because of that.
>
> > OK for trunk?
>
> No. So, I think this is wrong. The problem is that any synchronizing primitive can trapped by tsan and added to the analysis, and if it resolves the race, then it should change the analysis that tsan produces.
I disagree. Busy waiting of this kind is not appropriate for the testsuite,
we burn already way too much time and adding to that is undesirable.
tsan can't intercept the calls that you do through dlsym, because you
explicitly bypass tsan in that case.
> The point of the atomic set, load primitives and volatile, the code-gen is a single instruction that tsan by definition, wonât now, or ever instrument because we tell it explicitly, donât with no_sanitize_thread.
>
> Since gcc now supports no_sanitize_thread, I donât know of any reason why the test cases should not now be fixed to use step.
See above.
Jakub