This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [PATCH] libstdc++/77641 fix std::variant for literal types
- From: Tim Shen <timshen at google dot com>
- To: Jonathan Wakely <jwakely at redhat dot com>
- Cc: "libstdc++" <libstdc++ at gcc dot gnu dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 19 Sep 2016 13:06:45 -0700
- Subject: Re: [PATCH] libstdc++/77641 fix std::variant for literal types
- Authentication-results: sourceware.org; auth=none
- References: <20160919123409.GA8225@redhat.com>
On Mon, Sep 19, 2016 at 5:34 AM, Jonathan Wakely <jwakely@redhat.com> 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 used in the union in _Variant_storage.
>
> I'm not sure if the right condition is is_literal &&
> is_trivially_default_constructible, or if this is enough:
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 literal types are trivially destructible.
>
> PR libstdc++/77641
> * include/std/variant (__detail::__variant::_Uninitialized): Check
> is_trivially_default_constructible_v instead of is_literal_type_v.
> * testsuite/20_util/variant/compile.cc: Test literal type with
> non-trivial default constructor.
>
> Tim, are there case that this doesn't handle, where we need is_literal
> as well? (bear in mind that is_trivially_default_constructible also
> depends on trivially destructible).
I checked for is_default_constructible, and all other sites are appropriate.
--
Regards,
Tim Shen