Re: __GCC_HAVE_SYNC_COMPARE_AND_SWAP_16 not defined on aarch64

[Toebs Douglass <toby at winterflaw dot net>]

On 28/06/17 16:55, Richard Earnshaw wrote:
> On 28/06/17 08:27, Toebs Douglass wrote:

>> I'm not quite sure what this means.  I mean, I know what it means in a
>> literal and straightforward sense, but not in a larger sense.  From my
>> POV, writing user-mode code, aarch64 seems no different to any other
>> platform.  I have memory, I write to it, it gets written to.
>> Non-writeable memory would be ROM, no?  I wouldn't expect store returned
>> by malloc or allocated on stack won't be placed in ROM, and that's how I
>> get store to LL/SC on.

> It's a consequence of 'const' on pointers (and references) in C and C++
> meaning "cannot be modified in this context" but not precluding being
> modifiable in another context.  I can have const and non-const pointers
> to the same object in different threads.

Yes.

> If something is marked const I have no idea in general whether the
> program will cause a fault if the object is written to, or if the write
> will succeed anyway (it might be in a page marked as write-disabled, for
> example in the program text).

Yes.  But if I write to something I marked const, I've blundered.  It
seems no different to writing to store I have say already freed.

> So pointers to const atomic objects cannot use an LDXP/STXP loop because
> that might cause a fatal memory error but must also deal with the
> underlying object not being really constant and thus might be partially
> modified when accessed.  The only solution to that is to have a
> secondary lock on the object.

Wouldn't this just be considered undefined behaviour?

I may be wrong, but wouldn't the points made here also apply to normal
writes?