On Mon, Feb 15, 2016 at 10:07 AM, Bernd Edlinger <bernd.edlin...@hotmail.de> wrote: > On 15/02/16 09:07, Tom de Vries wrote: >>>On 15/02/16 08:24, Dmitry Vyukov wrote: >>> >>> If we are talking about pr 68580, then I would try: >>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68580#c2 >>> first. >> >> As I tried to explain in the follow-up comment ( >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68580#c3 ), >> since unfortunately I have no reliable way of reproducing the failure, >> there's no defined way to 'try' something. > > But your proposed patch is also only guessing.
Yeah, that's what I thought. Agree that general pthread_create failures should affect more tests. We can do both I guess. > Sure pthread_create can fail, as malloc and mmap. > But if that is the reason for the failure it would happen > just randomly, everywhere. > > Why do you think that only this test case shows the problem? > > I think Dmitry's comment may be right on the point. > > In pr65400-1.c we have > int v; int q; int o; > > be 4 byte aligned integers. > and at least > v and q share the same 8-byte tsan shadow memory slot. > > v and q are modified simultaniously, and each update > can be lost. > > The barrier wont help here, as it only synchronizes > accesses on v. > > So I think either we change int => long long > or add __attribute__((aligned(8))) to the variable declarations, > to make sure that each of them goes into a different memory > slot. > > > Regards, > Bernd. > >
