On Mon, Aug 3, 2015 at 6:06 PM, Alex Bennée <alex.ben...@linaro.org> wrote:
> > alvise rigo <a.r...@virtualopensystems.com> writes: > > > On Mon, Aug 3, 2015 at 12:30 PM, Alex Bennée <alex.ben...@linaro.org> > wrote: > >> > >> alvise rigo <a.r...@virtualopensystems.com> writes: > >> > >>> Hi Alex, > >>> > >>> Nice set of tests, they are proving to be helpful. > >>> One question below. > >>> > <snip> > >>> > >>> Why are we calling these last two instructions with the 'eq' suffix? > >>> Shouldn't we just strex r1, r0, [sptr] and then cmp r1, #0? > >> > >> Possibly, my armv7 is a little rusty. I'm just looking at tweaking this > >> test now so I'll try and clean that up. > > Please find the updated test attached. I've also included some new test > modes. In theory the barrier test by itself should still fail but it > Thanks, I will check them out. > passes on real ARMv7 as well as TCG. I'm trying to run the test on a > heavier core-ed ARMv7 to check. I suspect we get away with it on > ARMv7-on-x86_64 due to the strong ordering of the x86. > The "excl" and "acqrel" tests now run without issue (although again > plain acqrel semantics shouldn't stop a race corrupting shared_value). I suppose that, in order to have some race conditions due to a lack of a proper emulation of barriers and acqrel instructions, we need a test that does not involve atomic instructions at all, to reduce the emulation overhead as much as possible. Does this sound reasonable? > > I'll tweak the v8 versions of the test tomorrow. > > -- > Alex Bennée > >
