[libstdc++/65033] Give alignment info to libatomic

[Jonathan Wakely]

On 03/04/15 12:13 -0700, Richard Henderson wrote:
>On 04/03/2015 07:13 AM, Jonathan Wakely wrote:
>> +++ b/libstdc++-v3/include/std/atomic
>> @@ -165,9 +165,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>>      struct atomic
>>      {
>>      private:
>> -      // Align 1/2/4/8/16-byte types the same as integer types of that size.
>> +      // Align 1/2/4/8/16-byte types the natural alignment of that size.
>>        // This matches the alignment effects of the C11 _Atomic qualifier.
>> -      static constexpr int _S_min_alignment
>> +      static constexpr int _S_int_alignment
>>  	= sizeof(_Tp) == sizeof(char)	   ? alignof(char)
>>  	: sizeof(_Tp) == sizeof(short)	   ? alignof(short)
>>  	: sizeof(_Tp) == sizeof(int)	   ? alignof(int)
>> @@ -178,6 +178,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>>  #endif
>>  	: 0;
>>
>> +      static constexpr int _S_min_alignment
>> +	= _S_int_alignment > sizeof(_Tp) ? _S_int_alignment : sizeof(_Tp);
>> +
>
>This doesn't work for non-power-of-two sized _Tp.
>
>Again, we don't have *any* target for which alignof(integer) > sizeof(integer).
>So if you care about forcing natural alignment, don't bother with the alignof
>on the integrals, as you're doing with _S_int_alignment at the moment.

OK, the attached patch uses the simpler version you proposed, so
integral types and non-integral types with size 1/2/4/8/16 are aligned
to at least their size.

What about the __atomic_base<_PTp*> partial specialization for
pointers, do we need to use alignas on its data member, or are
pointers always aligned appropriately on all targets?

And what about these lines:

  void *__a = reinterpret_cast<void *>(-__alignof(_M_i));
  return __atomic_is_lock_free(sizeof(_M_i), __a);

Do we still need that if we use alignas on the data members?
If we do, do you agree with HP that it should use _S_alignment not
__alignof(_M_i)? That seems redundant to me once _M_i has been given a
fixed alignment with alignas.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch.txt
Type: text/x-patch
Size: 5211 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20150407/48178b4f/attachment.bin>