RFR: 8186166: Generalize Atomic::cmpxchg with templates

[Kim Barrett]

> On Aug 18, 2017, at 10:08 AM, Andrew Haley <aph at redhat.com> wrote:
> 
> On 18/08/17 14:21, Andrew Haley wrote:
>> More seriously, IMO: accessing a stored pointer to X as though it had
>> been stored as a void* is certainly undefined behaviour, by the rule
>> you point out above.  It seems to me that you are worried about some
>> things that are relatively minor, while ignoring things that are
>> serious.
>> 
>> If you followed the approach of never converting the type of the
>> pointer to dest to some other point, *but instead converting the types
>> of exchange_value and compare_value* everything would be fine.  This
>> whole thing could be done with no UB at all.
> 
> Looking at your patch again, I think that I've got this wrong: you're
> doing it the right way here:
> 
> struct Atomic::CmpxchgImpl<
>  T*, D*, U*,
>  typename EnableIf<Atomic::IsPointerConvertible<T*, D*>::value &&
>                    IsSame<typename RemoveCV<D>::type,
>                           typename RemoveCV<U>::type>::value>::type>
>  VALUE_OBJ_CLASS_SPEC
> {
>  D* operator()(T* exchange_value, D* volatile* dest, U* compare_value,
>               cmpxchg_memory_order order) const {
>    // Allow derived to base conversion, and adding cv-qualifiers.
>    D* new_value = exchange_value;
>    // Don't care what the CV qualifiers for compare_value are,
>    // but we need to match D* when calling platform support.
>    D* old_value = const_cast<D*>(compare_value);
> 
> My apologies.

Thanks.

The questionable conversions are now confined to platform-specific
code, for those platforms that have made the choice to use a
fixed-type out-of-line helper function as the ultimate implementation.

For platforms that use type-generic compiler intrinsics
(linux_aarch64, for example), or type-generic inline assembler
(several), such conversions are not needed.