On Nov 3, 2014, Mark Thompson <mrt@xxxxxxxxx> wrote: > I disagree with this reasoning, though I am not sufficiently familiar > with the standards involved to argue with it effectively. > However, I do see a more concerning point here: does this argument > also apply to memcpy()? If the argument is correct, then I don't see why it wouldn't. The discussion has been ongoing in glibc-alpha, but it's not clear that any argument any of us might bring up at this point would amount to global consensus on what the standards actually meant, so I take it they're more like exploring what is already defined and what isn't, to perhaps later seek clarification from the standard bodies. > Given that, does it not follow that the current, released, > implementation of memcpy() in glibc for architectures using a wh64 > instruction (alpha, tilepro and tilegx) is entirely wrong? If the argument, as stated, is correct, yes. There's an alternative argument that wouldn't rule it out, though, that amounts to requiring the implementation to stick to the stated specification of *copying* data from source to destination (as opposed to writing random bits in dest until it compares equal to source), but with enough leeway to make copying behavior that performs cache-line invalidation when there is certainty that the entire cache line is going to be overwritten. It is hard to specify that formally, but the intuitive notion could be that, if the implementation does what the spec says it should (namely, reading from source and storing in target), besides ensuring the postconditions are met if the preconditions were met to begin with, without modifying memory that shouldn't have been modified, it could be ok. That's not my reading, but it's a possibility the standard bodies might consider if the intent is to rule out garbage writing but not cache invalidation. -- Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
