This is an archive of the discontinued LLVM Phabricator instance.

[libcxx] Diagnose invalid memory order arguments in <atomic>. Fixes PR21179.
ClosedPublic

Authored by EricWF on Jul 19 2016, 6:58 PM.

Details

Summary

This patch uses the attribute((enable_if)) hack suggested by @rsmith to diagnose invalid arguments when possible.

In order to diagnose an invalid argument m to f(m) we provide an additional overload of f that is only enabled when m is invalid. When that function is enabled it uses attribute((unavailable)) to produce a diagnostic message.

Diff Detail

Event Timeline

EricWF updated this revision to Diff 64629.Jul 19 2016, 6:58 PM
EricWF retitled this revision from to [libcxx] Diagnose invalid memory order arguments in <atomic>. Fixes PR21179..
EricWF updated this object.
EricWF added reviewers: mclow.lists, rsmith.
EricWF added subscribers: cfe-commits, rsmith.
jfb added a subscriber: jfb.Jul 20 2016, 11:40 AM

Awesome, thanks for doing this!

Should this be a warning or an error?

include/atomic
581

This isn't checking for the following requirement from the standard:

The failure argument shall be no stronger than the success argument.

I think that's OK because I intend to remove that requirement from C++ :)

Should we nonetheless enforce the requirement until the standard drops it? If so, "stronger" isn't well defined by the standard, details here: https://github.com/jfbastien/papers/blob/master/source/D0418r1.bs

test/libcxx/atomics/diagnose_invalid_memory_order.fail.cpp
30

Could you test that the other memory orders don't have any diagnostic (here and below).

55

For cmpxchg (weak and strong), should you also test the version with only a success ordering? The failure one is auto-generated from success, but it would be good to know that it never generates a diagnostic.

bcraig added a subscriber: bcraig.Jul 20 2016, 11:59 AM
bcraig added inline comments.
include/atomic
569

what about relaxed?

jfb added inline comments.Jul 20 2016, 3:46 PM
include/atomic
569

Load relaxed is valid.

EricWF marked 2 inline comments as done.Jul 20 2016, 7:20 PM
EricWF added inline comments.
include/atomic
581

Because "stronger" lacks a solid definition I choose not to implement checks for that requirement. I believe Clang does as well.

I think that's OK because I intend to remove that requirement from C++ :)

Yet another reason to not implement it.

EricWF updated this revision to Diff 64808.Jul 20 2016, 7:21 PM

Add tests for valid memory orderings as well. Originally I figured the rest of the test suite should cover them but there's no harm in more tests.

bcraig added inline comments.Jul 21 2016, 7:13 AM
include/atomic
569

Gah, read the logic backwards... and even backwards my comments are incomplete.

jfb added a comment.Jul 21 2016, 10:38 AM

Two comments, then lgtm.

include/atomic
581

OK that's totally fine with me. Could you put this in a comment? Something like "not checking the 'stronger' requirement, see wg21.link/p0418" (it'll be published in the pre-Issaquah meeting, URL will work then).

test/libcxx/atomics/diagnose_invalid_memory_order.fail.cpp
87

Could you do the other 5 (same below).

EricWF added a reviewer: jfb.Jul 22 2016, 1:36 PM
EricWF marked an inline comment as done.

Address inline comments from @jfb and add him as a reviewer.

test/libcxx/atomics/diagnose_invalid_memory_order.fail.cpp
87

I could, but we only check the two argument version of the overload, so I *know* the other orderings will have the same result. I think the one test is sufficient because it will fail the second we start testing the one argument version.

Do you still want the additional tests?

EricWF updated this revision to Diff 65140.Jul 22 2016, 1:39 PM

Add comment about checking "stronger" orderings.

jfb added inline comments.Jul 22 2016, 4:31 PM
test/libcxx/atomics/diagnose_invalid_memory_order.fail.cpp
88

That's not quite true: the failure ordering is auto-deduced from the success one, but it's not necessarily the same! The spec says all success is valid, so the auto-mapping has to ensure that all failures are also valid. That's what I'm trying to have you test: that the auto-mapping is always valid as well.

EricWF added inline comments.Jul 22 2016, 4:44 PM
test/libcxx/atomics/diagnose_invalid_memory_order.fail.cpp
88

Right, but the auto-mapping is done once we have entered the compare_exchange_weak function, These diagnostics are triggered within the function signature. So even if we got the auto mapping wrong this test would not be able to diagnose it.

I agree we should be testing the auto-mapping, but I don't think this test is the right place to do it.

EricWF accepted this revision.Jul 22 2016, 6:23 PM
EricWF added a reviewer: EricWF.
This revision is now accepted and ready to land.Jul 22 2016, 6:23 PM
EricWF closed this revision.Jul 22 2016, 6:24 PM