From: David Miller <da...@davemloft.net> Date: Tue, 09 Jun 2015 00:34:14 -0700 (PDT) > > Your test is faulty. > > You cannot use ASI_BLK_P loads or stores without appropriate memory > barriers around them.
Um, but my test isn't testing what is being stored to memory at all. It is storing to memory and **never loading from the memory after**. Why would writing FROM fp registers TO memory corrupt the *registers* due to a missing memory barrier? If problem 1 is due to a missing membar somewhere, I think it's surely gotta be the kernel that's missing it, not my test code. No? On Jun 9, 2015 3:46 AM, "David Miller" <da...@davemloft.net> wrote: > > FWIW, you're probably hitting the bug fixed by the following commit in > glibc: > > commit 834caf06f33d79be54cff63c274fba2845513593 > Author: Jose E. Marchesi <jose.march...@oracle.com> > Date: Sat May 17 11:20:27 2014 -0700 > > Fix sparc memcpy data corruption when using niagara2 optimized routines. > > * sysdeps/sparc/sparc64/multiarch/memcpy-niagara2.S: Add missing > membar to avoid block loads/stores to overlap previous stores. > Debian glibc has multiarch support disabled (done a couple years ago to try to workaround the unreliability, not entirely successfully..), so it's not using that routine you mention. It's using sysdeps/sparc/sparc32/sparcv9/memcpy.S which points to sysdeps/sparc/sparc64/memcpy.S
