Sort out volatiles in the atomic functions #6368
Conversation
The volatile qualifier on the __LDREX/__STREX prototypes only means that it's safe to use them on volatile objects. Doesn't mean you actually have to pass them volatile pointers. Adding the volatile is a bit like doing strlen((const char *) ptr) because you've got a non-const pointer.
The atomic functions preserve volatile semantics - they only perform the accesses specified. Add the volatile qualifier to the value pointer to reflect this. This does not change existing caller code - it's equivalent to adding a const qualifier to indicate we don't write to a pointer - it means people can pass us qualified pointers without casts, letting the compile check const- or volatile-correctness. This is consistent with C11 <stdatomic.h>, which volatile-qualifies its equivalent functions. Note that this useage of volatile has nothing to do with the atomicity - objects accessed via the atomic functions do not need to be volatile. But it does permit these calls to be used on objects which have been declared volatile.
|
Do shout if you can see a way this would break any existing code - as far as I can see it's equivalent to adding a missing Only thing I can think of is someone having a local declaration, or a dummy definition in a unit test. |
|
/morph build |
Build : FAILUREBuild number : 1491 |
|
/morph build |
Build : FAILUREBuild number : 1492 |
|
License failure, will restart soon |
|
/morph build |
Build : SUCCESSBuild number : 1495 Triggering tests/morph test |
Exporter Build : SUCCESSBuild number : 1139 |
Test : SUCCESSBuild number : 1278 |
Description
Code clean up - the atomic code is confused about the use and meaning of
volatile. It's using casts internally where not necessary, and potentially forcing users to insert casts.Only visible change to application code is that
will now work - previously it would have required
This will continue to work:
Change broken into two individual commits to try to avoid impression that the net change is just expecting users to be providing volatile objects - see commit messages for more detail.
(Given the lack of a full suite of atomic operations including load and store, it's probably the case that users will be currently needing to mark stuff volatile just to avoid compiler optimisations. If we do get a full suite of atomic operations, and that would be required for SMP, then there would usually be no need for volatile, but could be in some cases. This change makes us consistent with C11/C++11 regardless).
Pull request type