On 01/13/2015 10:20 AM, Torvald Riegel wrote:
On Tue, 2015-01-13 at 09:56 -0500, Andrew MacLeod wrote:
The problem with the patch in the PR is the memory model is immediately
promoted from consume to acquire. This happens *before* any of the
memmodel checks are made. If a consume is illegally specified (such as
in a compare_exchange), it gets promoted to acquire and the compiler
doesn't report the error because it never sees the consume.
The only issue I can think of in compare_exchange is if the program
specifies memory_order_consume for the success path but
memory_order_acquire for the failure path, which is disallowed by the
standard.
However, I don't see a reason why the standard's requirement is anything
but a performance check in our particular case. The only case we
prevent the compiler from reporting is a consume-on-success /
acquire-on-failure combination. But we upgrade the former to acquire,
so we can't even cause libatomic (or similar) to issue too weak barriers
due to libatomic relying on the standard's requirement.
Thus, if there's no easy way to upgrade to acquire after the sanity
checks, I think this isn't critical enough to hold up the patch from
being committed. memory_order_consume is clearly a feature for experts.
The error was actually in exchange... not compare_exchange like I wrote.
and causes a testsuite error that specifically tests for an illegal
consume.
Andrew
