Re: [PATCH] libstdc++/77641 fix std::variant for literal types

2016-09-22 Thread Jonathan Wakely
On 21/09/16 20:23 -0700, Tim Shen wrote: On Wed, Sep 21, 2016 at 1:52 AM, Jonathan Wakely wrote: THanks, OK for trunk. Committed. This fixes the pretty printer. Committed to trunk. commit 6b869af56fa80da5b746390ce5616ebebcc0bd5d Author: redi

Re: [PATCH] libstdc++/77641 fix std::variant for literal types

2016-09-22 Thread Jonathan Wakely
On 22/09/16 09:37 +0100, Jonathan Wakely wrote: On 22/09/16 09:45 +0300, Ville Voutilainen wrote: This problem is not introduced by the latest patch, but it's something that we should look at anyway. There's been recent discussion about what assignments do with variants that hold references.

Re: [PATCH] libstdc++/77641 fix std::variant for literal types

2016-09-22 Thread Jonathan Wakely
On 22/09/16 09:45 +0300, Ville Voutilainen wrote: This problem is not introduced by the latest patch, but it's something that we should look at anyway. There's been recent discussion about what assignments do with variants that hold references. Consider this: #include int main() { float f1

Re: [PATCH] libstdc++/77641 fix std::variant for literal types

2016-09-22 Thread Ville Voutilainen
This problem is not introduced by the latest patch, but it's something that we should look at anyway. There's been recent discussion about what assignments do with variants that hold references. Consider this: #include int main() { float f1 = 1.0f, f2 = 2.0f; std::variant v1(f1);

Re: [PATCH] libstdc++/77641 fix std::variant for literal types

2016-09-21 Thread Tim Shen
On Wed, Sep 21, 2016 at 1:52 AM, Jonathan Wakely wrote: > THanks, OK for trunk. Committed. Thanks! -- Regards, Tim Shen

Re: [PATCH] libstdc++/77641 fix std::variant for literal types

2016-09-21 Thread Jonathan Wakely
On 20/09/16 11:03 -0700, Tim Shen wrote: On Mon, Sep 19, 2016 at 1:06 PM, Tim Shen wrote: I believe that it's a "typo" from me - it should be is_trivially_destructible, not is_default_constructible (so that we can avoid using aligned_storage in the corresponding

Re: [PATCH] libstdc++/77641 fix std::variant for literal types

2016-09-20 Thread Tim Shen
On Mon, Sep 19, 2016 at 1:06 PM, Tim Shen wrote: > I believe that it's a "typo" from me - it should be > is_trivially_destructible, not is_default_constructible (so that we > can avoid using aligned_storage in the corresponding specialization). > is_literal_type works, since

Re: [PATCH] libstdc++/77641 fix std::variant for literal types

2016-09-19 Thread Tim Shen
On Mon, Sep 19, 2016 at 5:34 AM, Jonathan Wakely wrote: > As noted in bugzilla PR 77641 I don't think is_literal_type is the > right condition for _Uninitialized, because a type can have a > non-trivial default constructor but still be literal, but that means > it can't be

[PATCH] libstdc++/77641 fix std::variant for literal types

2016-09-19 Thread Jonathan Wakely
As noted in bugzilla PR 77641 I don't think is_literal_type is the right condition for _Uninitialized, because a type can have a non-trivial default constructor but still be literal, but that means it can't be used in the union in _Variant_storage. I'm not sure if the right condition is