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.
