On Mon, Feb 15, 2016 at 1:44 PM, Bernd Edlinger <bernd.edlin...@hotmail.de> wrote: > 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
Looks good to me then.
