[cfe-dev] [libcxx] std::atomic default constructor

[Stephan Tolksdorf]

On 02.05.13 20:05, Howard Hinnant wrote:
> Hi Stephan,
>
> Sorry for the delay in reviewing this.  I questioned every decision you made, and every time came up with the same answer you did.  Nice job. :-)

Thanks!

> My only complaint is that there's no entry for you in CREDITS.TXT.

You could use something like the following:

N: Stephan Tolksdorf
E: st at quanttec.com
D: Minor <atomic> fix

>
> Please feel free to commit this, or if you would prefer, I will.

Please commit, I don't have commit rights.

Thank you for the review and the committing!

- Stephan

>
> On Apr 26, 2013, at 5:52 PM, Stephan Tolksdorf <st at quanttec.com> wrote:
>
>> I've attached a diff that fixes the issue in the <atomic> header and adds corresponding tests. I've used macros to fall back to a user-provided default constructor if _LIBCPP_HAS_NO_DEFAULTED_FUNCTIONS (though I suspect that there won't be many users defining that macro).
>>
>> The tests use placement new to check that atomic values get properly zero-initialized. I had to modify the atomic_is_lock_free test, because "default initialization of an object of const type 'const A' (aka 'const atomic<int>') requires a user-provided default constructor".
>>
>> - Stephan
>>
>> On 26.04.13 17:21, Howard Hinnant wrote:
>>> I do not know if it will be in time or not for the next clang release.  I would be happy review such a patch.  I'd prefer a patch that switches on cxx_defaulted_functions, though I note that <atomic> doesn't compile at all in C++03 mode anyway.  So the only advantage would be that <atomic> might work on some hypothetical compiler that had cxx_atomic but not cxx_defaulted_functions.  I haven't investigated to know if this is a possibility.
>>>
>>> Howard
>>>
>>> On Apr 26, 2013, at 6:46 AM, Stephan Tolksdorf <st at quanttec.com> wrote:
>>>
>>>> Hi Howard,
>>>>
>>>> If I prepare a patch for the <atomic> header, can this still be fixed in time for the next Clang release? Or maybe you already have this on your todo list? It seems like a relatively ugly correctness issue that should be easy to fix.
>>>>
>>>> Best regards,
>>>>   Stephan
>>>>
>>>> On 15.03.13, Howard Hinnant wrote:
>>>>> Looks like a bug that needs fixing.  When I wrote <atomic>, = default wasn't implemented yet.  The entire library needs to be scanned for this issue.  And the fix needs to be macro'd up so that we don't break C++03 mode more than it already is.
>>>>>
>>>>> Howard
>>>>>
>>>>> On Mar 15, 2013, at 3:50 PM, Stephan Tolksdorf <st at quanttec.com> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Is there a reason that the default constructors for the std::atomic types in libc++'s <atomic> are not explicitly defaulted? In the header the "= default" is commented out and instead a trivial constructor is explicitly defined. This leads to non-standard behaviour, because value initialization doesn't zero-initialize the atomic value.
>>>>>>
>>>>>> For example, the default constructor of the following struct Test does not zero-initialize atomicValue as expected:
>>>>>>
>>>>>> struct Test {
>>>>>>     int value{}; // is zero-initialized
>>>>>>     std::atomic<int> atomicValue{}; // is not zero-initialized
>>>>>> };
>>>>>>
>>>>>> Best regards,
>>>>>>   Stephan
>>>>>>
>>>>>> _______________________________________________
>>>>>> cfe-dev mailing list
>>>>>> cfe-dev at cs.uiuc.edu
>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>> <atomic.diff>
>
>