[Bug libstdc++/94033] is_trivially_copy_constructible<> fails with compiler error on complicated object with private default constructor

[Bug libstdc++/94033] is_trivially_copy_constructible<> fails with compiler error on complicated object with private default constructor

[rafael at espindo dot la]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94033

--- Comment #5 from Rafael Avila de Espindola <rafael at espindo dot la> ---
The regression (at least with the reduced testcase I uploaded) is from:

commit 58487c21b6a47c3fff6c6958684de866216a5593 (HEAD)
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Mon May 20 12:32:51 2019 +0100

    PR c++/90532 Ensure __is_constructible(T[]) is false

[Bug libstdc++/94033] [10 Regression] is_trivially_copy_constructible<> fails with compiler error on complicated object with private default constructor

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94033

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Target Milestone|---                         |10.0
            Version|unknown                     |10.0
           Assignee|unassigned at gcc dot gnu.org      |redi at gcc dot gnu.org
      Known to fail|                            |10.0
            Summary|is_trivially_copy_construct |[10 Regression]
                   |ible<> fails with compiler  |is_trivially_copy_construct
                   |error on complicated object |ible<> fails with compiler
                   |with private default        |error on complicated object
                   |constructor                 |with private default
                   |                            |constructor
     Ever confirmed|0                           |1
      Known to work|                            |9.2.1
   Last reconfirmed|                            |2020-03-11
           Priority|P3                          |P1

[Bug libstdc++/94033] [10 Regression] is_trivially_copy_constructible<> fails with compiler error on complicated object with private default constructor

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94033

--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I think that change to the compiler was OK, but it looks like the accompanying
"simplification" of <type_traits> was the culprit. Thanks for the bisection.

[Bug libstdc++/94033] [10 Regression] is_trivially_copy_constructible<> fails with compiler error on complicated object with private default constructor

[avi@cloudius-systems.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94033

--- Comment #7 from Avi Kivity <avi@cloudius-systems.com> ---
That commit is in gcc 9.3, so I'm guessing 9.3 is affected too.

5c7938eb3f1a116b1cf9a28090f2cc5e08814ce4 tags/releases/gcc-9.3.0~221

[Bug libstdc++/94033] [10 Regression] is_trivially_copy_constructible<> fails with compiler error on complicated object with private default constructor

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94033

--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> ---
5c7938eb3f1a116b1cf9a28090f2cc5e08814ce4 is a different change to
58487c21b6a47c3fff6c6958684de866216a5593

The gcc-9 commit that corresponds to 58487c21b6a47c3fff6c6958684de866216a5593 
is d9940358fa46306072ce408c4b5a1fcb3d01a0a2 which was already in gcc-9.2.0

[Bug libstdc++/94033] [10 Regression] is_trivially_copy_constructible<> fails with compiler error on complicated object with private default constructor

[avi@cloudius-systems.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94033

--- Comment #9 from Avi Kivity <avi@cloudius-systems.com> ---
Thanks. I'll test 9.3 as soon as it hits koji.

[Bug libstdc++/94033] [10 Regression] is_trivially_copy_constructible<> fails with compiler error on complicated object with private default constructor

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94033

--- Comment #10 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I have a fix for master, I'm just trying to figure out why we aren't seeing
this on the gcc-9 branch too.

[Bug libstdc++/94033] [10 Regression] is_trivially_copy_constructible<> fails with compiler error on complicated object with private default constructor

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94033

--- Comment #11 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I think it doesn't show up for gcc-9 because there are also std::tuple changes
on master that make the bug show up.

And I think what's happening is another instance of PR 41437. When
std::optional<mutation> is instantiated it causes
std::is_constructible<mutation> to be instantiated, but gives the wrong answer
because of PR 41437.

Later when the value of std::is_nothrow_default_constructible<mutation> is
needed, the bad instantiation of is_constructible<mutation> is reused, which
means that the first condition in the __and_ here is true (but shouldn't be)
and so we try the second condition, which is ill-formed:

  /// is_nothrow_default_constructible
  template<typename _Tp>
    struct is_nothrow_default_constructible
    : public __and_<is_default_constructible<_Tp>,
                    __is_nt_default_constructible_impl<_Tp>>
    { };

/home/jwakely/gcc/10/include/c++/10.0.1/type_traits:966:47: error:
'mutation::mutation()' is private within this context
  966 |     : public integral_constant<bool, noexcept(_Tp())>
      |                                               ^~~~~

We should never try to construct _Tp() when it isn't default constructible. The
cached bad value of is_constructible<mutation> makes us try to do something
impossible.

Lending weight to this theory is the fact that explicitly checking
is_constructible_v<mutation> *before* instantiating optional<mutation> makes
the bug go away:

#include <optional>
#include <tuple>
template <bool B> struct abc {};
template <typename T>
struct future : public
abc<std::is_trivially_constructible<std::tuple<T>>::value> {};
class mutation {
  mutation();
  friend class std::optional<mutation>;
};
#ifdef FIX
static_assert( !std::is_nothrow_default_constructible<mutation>::value );
#endif
using mutation_opt = std::optional<mutation>;
future<mutation_opt> foo();
template <typename Consumer> future<mutation_opt> consume_partitions() {
  return foo();
}
future<mutation_opt> bar() { return consume_partitions<int>(); }
future<mutation> zed();
future<mutation> apply_counter_update() { return zed(); }

Define FIX to make the bug vanish.

[Bug libstdc++/94033] [10 Regression] is_trivially_copy_constructible<> fails with compiler error on complicated object with private default constructor

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94033

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=94003

--- Comment #12 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #11)
> #ifdef FIX
> static_assert( !std::is_nothrow_default_constructible<mutation>::value );
> #endif

Or slightly simpler, just instantiate the trait that's giving the wrong answer,
which others depend on:

#ifdef FIX
static_assert( !std::is_constructible<mutation>::value );
#endif


See also PR 94003.

Anyway, I have a patch for the library traits to avoid the problem.

[Bug libstdc++/94033] [10 Regression] is_trivially_copy_constructible<> fails with compiler error on complicated object with private default constructor

[avi@cloudius-systems.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94033

--- Comment #13 from Avi Kivity <avi@cloudius-systems.com> ---
Can you attach the patch here please?

I'd like to test that this is the only blocker for adopting gcc 10 for us, so
that we can adopt it as soon as it is released. I'm anxious to start using
coroutines.

[Bug libstdc++/94033] [10 Regression] is_trivially_copy_constructible<> fails with compiler error on complicated object with private default constructor

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94033

--- Comment #14 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Created attachment 48044
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48044&action=edit
Candidate patch

[Bug libstdc++/94033] [10 Regression] is_trivially_copy_constructible<> fails with compiler error on complicated object with private default constructor

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94033

--- Comment #15 from Jonathan Wakely <redi at gcc dot gnu.org> ---
The reason I haven't committed it yet is I had to figure out a workaround for
PR 94197 which caused some tests to fail with my earlier patch.

[Bug libstdc++/94033] [10 Regression] is_trivially_copy_constructible<> fails with compiler error on complicated object with private default constructor

[avi@cloudius-systems.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94033

--- Comment #16 from Avi Kivity <avi@cloudius-systems.com> ---
I confirm this fixes my original problem, not just the reduced test case.

[Bug libstdc++/94033] [10 Regression] is_trivially_copy_constructible<> fails with compiler error on complicated object with private default constructor

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94033

--- Comment #17 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Thanks! And PR 94197 is also now fixed.

[Bug libstdc++/94033] [10 Regression] is_trivially_copy_constructible<> fails with compiler error on complicated object with private default constructor

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94033

--- Comment #18 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jonathan Wakely <redi@gcc.gnu.org>:

https://gcc.gnu.org/g:b3341826531e80e02f194460b4fbe1b0541c0463

commit r10-7270-gb3341826531e80e02f194460b4fbe1b0541c0463
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Wed Mar 18 23:19:12 2020 +0000

    libstdc++: Fix is_trivially_constructible (PR 94033)

    This attempts to make is_nothrow_constructible more robust (and
    efficient to compile) by not depending on is_constructible. Instead the
    __is_constructible intrinsic is used directly. The helper class
    __is_nt_constructible_impl which checks whether the construction is
    non-throwing now takes a bool template parameter that is substituted by
    the result of the instrinsic. This fixes the reported bug by not using
    the already-instantiated (and incorrect) value of std::is_constructible.
    I don't think it really fixes the problem in general, because
    std::is_nothrow_constructible itself could already have been
    instantiated in a context where it gives the wrong result. A proper fix
    needs to be done in the compiler.

            PR libstdc++/94033
            * include/std/type_traits (__is_nt_default_constructible_atom):
Remove.
            (__is_nt_default_constructible_impl): Remove.
            (__is_nothrow_default_constructible_impl): Remove.
            (__is_nt_constructible_impl): Add bool template parameter. Adjust
            partial specializations.
            (__is_nothrow_constructible_impl): Replace class template with
alias
            template.
            (is_nothrow_default_constructible): Derive from alias template
            __is_nothrow_constructible_impl instead of
            __is_nothrow_default_constructible_impl.
            * testsuite/20_util/is_nothrow_constructible/94003.cc: New test.

[Bug libstdc++/94033] [10 Regression] is_trivially_copy_constructible<> fails with compiler error on complicated object with private default constructor

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94033

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|ASSIGNED                    |RESOLVED

--- Comment #19 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Should be fixed now. Thanks for the testcases and testing.

[Bug libstdc++/94033] [10 Regression] is_trivially_copy_constructible<> fails with compiler error on complicated object with private default constructor

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94033

--- Comment #20 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-9 branch has been updated by Jonathan Wakely
<redi@gcc.gnu.org>:

https://gcc.gnu.org/g:6d06c17e9f470f4a2d7e41ca6f3a8b36c729dc6a

commit r9-8860-g6d06c17e9f470f4a2d7e41ca6f3a8b36c729dc6a
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Wed Mar 18 23:19:12 2020 +0000

    libstdc++: Fix is_trivially_constructible (PR 94033)

    This attempts to make is_nothrow_constructible more robust (and
    efficient to compile) by not depending on is_constructible. Instead the
    __is_constructible intrinsic is used directly. The helper class
    __is_nt_constructible_impl which checks whether the construction is
    non-throwing now takes a bool template parameter that is substituted by
    the result of the instrinsic. This fixes the reported bug by not using
    the already-instantiated (and incorrect) value of std::is_constructible.
    I don't think it really fixes the problem in general, because
    std::is_nothrow_constructible itself could already have been
    instantiated in a context where it gives the wrong result. A proper fix
    needs to be done in the compiler.

    Backported to the gcc-8 and gcc-9 branches to fix PR 96999.

            PR libstdc++/94033
            * include/std/type_traits (__is_nt_default_constructible_atom):
Remove.
            (__is_nt_default_constructible_impl): Remove.
            (__is_nothrow_default_constructible_impl): Remove.
            (__is_nt_constructible_impl): Add bool template parameter. Adjust
            partial specializations.
            (__is_nothrow_constructible_impl): Replace class template with
alias
            template.
            (is_nothrow_default_constructible): Derive from alias template
            __is_nothrow_constructible_impl instead of
            __is_nothrow_default_constructible_impl.
            * testsuite/20_util/is_nothrow_constructible/94003.cc: New test.

    (cherry picked from commit b3341826531e80e02f194460b4fbe1b0541c0463)

[Bug libstdc++/94033] [10 Regression] is_trivially_copy_constructible<> fails with compiler error on complicated object with private default constructor

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94033

--- Comment #21 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-8 branch has been updated by Jonathan Wakely
<redi@gcc.gnu.org>:

https://gcc.gnu.org/g:1521433e2b6bff583b227fe391fe9dcf02f6000e

commit r8-10445-g1521433e2b6bff583b227fe391fe9dcf02f6000e
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Wed Mar 18 23:19:12 2020 +0000

    libstdc++: Fix is_trivially_constructible (PR 94033)

    This attempts to make is_nothrow_constructible more robust (and
    efficient to compile) by not depending on is_constructible. Instead the
    __is_constructible intrinsic is used directly. The helper class
    __is_nt_constructible_impl which checks whether the construction is
    non-throwing now takes a bool template parameter that is substituted by
    the result of the instrinsic. This fixes the reported bug by not using
    the already-instantiated (and incorrect) value of std::is_constructible.
    I don't think it really fixes the problem in general, because
    std::is_nothrow_constructible itself could already have been
    instantiated in a context where it gives the wrong result. A proper fix
    needs to be done in the compiler.

    Backported to the gcc-8 and gcc-9 branches to fix PR 96999.

            PR libstdc++/94033
            * include/std/type_traits (__is_nt_default_constructible_atom):
Remove.
            (__is_nt_default_constructible_impl): Remove.
            (__is_nothrow_default_constructible_impl): Remove.
            (__is_nt_constructible_impl): Add bool template parameter. Adjust
            partial specializations.
            (__is_nothrow_constructible_impl): Replace class template with
alias
            template.
            (is_nothrow_default_constructible): Derive from alias template
            __is_nothrow_constructible_impl instead of
            __is_nothrow_default_constructible_impl.
            * testsuite/20_util/is_nothrow_constructible/94003.cc: New test.

    (cherry picked from commit b3341826531e80e02f194460b4fbe1b0541c0463)

[Bug libstdc++/94033] [10 Regression] is_trivially_copy_constructible<> fails with compiler error on complicated object with private default constructor

[ppalka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94033
Bug 94033 depends on bug 94197, which changed state.

Bug 94197 Summary: __is_constructible gives an access error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94197

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED