On 15/02/16 13:05, Dmitry Vyukov wrote: > On Mon, Feb 15, 2016 at 12:29 PM, Bernd Edlinger > <bernd.edlin...@hotmail.de> wrote: >> >> No problem. PR65400 was a GCC wrong code bug, so it makes no >> sense to have the same test in llvm's tree, thus we are free to fix it on >> our own, as we like. >> >> Here is a patch that puts each value on it's own 8-byte aligned memory >> location. From my experience with tsan tests, sharing shadow memory >> slots between v and q or o is the most likely explanation for the occasional >> inability to spot the race condition on v, thus the test case fails, because >> the return code is 0, and the expected output is not found. >> >> >> Boot-strapped/regression tested on x86_64-linux-gnu. >> >> OK for trunk? > > > I don't know whether it will fire or not, but 4-byte variables that > are 8-byte aligned can still be collocated with something else. Making > vars 8-byte should be safer.
Yes, but as PR65400 is a wrong code bug, I would not like to change more than absolutely necessary to the test case, in order not to loose the ability to check the original regression. The test case does not have more than the 3 global values that you see. nm a.out | sort shows that these are now separate: 0000000000601400 b barrier 0000000000601420 b barrier_wait 0000000000601428 B v 0000000000601430 B o 0000000000601438 B q 0000000000601440 B _end Regards, Bernd.
