From: James Y Knight <jyknight@xxxxxxxxxx> Date: Tue, 9 Jun 2015 08:13:58 -0400 > 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? The memory barrier is necessary for two reasons, only one of them is to handle the asynchronousness of the memory operations. The other reason is that there are strict rules for accessing the FPU register file around block loads and stores. Therefore if you don't do the proper memory barriers you can get corrupted FPU register as well as memory contents. And complicating things even more, what you can get away with is different on every single cpu variant. That's why I really wish debian didn't disable multiarch as that makes the code use the UltraSPARC-I/II/III memcpy, which might not be %100 kosher on Niagara-T1 and later. Anyways, please put proper memory barriers into your testcase and let's see if the problem still triggers. Thanks. -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
