From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
 id 36F47386F43C; Tue, 21 Apr 2020 08:26:23 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 36F47386F43C
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
 s=default; t=1587457583;
 bh=g8e438noWQP/iWfPqIOe8t0kxXgTJc3zTeRHEzk75Mw=;
 h=From:To:Subject:Date:In-Reply-To:References:From;
 b=MeRrBOR+TNSESCsr6hpjZR8RS+j2cXTohWLfHELu73C7FYmKtlskkZIfcBawLT+9A
 GUGBC6DElQn1I5NHOap5F2YBzTt0iPBsYI6UaNJnzTzjO8F16gxOOWRnZ+tGtd01CV
 E+TIChWTnygjiVoazp+KKrckB1G21US4m5cV7t9E=
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/94679] link time error: undefined reference to
 std::projected<...>::operator *() const
Date: Tue, 21 Apr 2020 08:26:23 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 10.0
X-Bugzilla-Keywords: link-failure
X-Bugzilla-Severity: normal
X-Bugzilla-Who: redi at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: component everconfirmed keywords cf_reconfirmed_on
 bug_status
Message-ID: <bug-94679-4-qh52KBPIGa@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-94679-4@http.gcc.gnu.org/bugzilla/>
References: <bug-94679-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: gcc-bugs@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-bugs mailing list <gcc-bugs.gcc.gnu.org>
List-Unsubscribe: <http://gcc.gnu.org/mailman/options/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-request@gcc.gnu.org?subject=help>
List-Subscribe: <http://gcc.gnu.org/mailman/listinfo/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Apr 2020 08:26:23 -0000

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|libstdc++                   |c++
     Ever confirmed|0                           |1
           Keywords|                            |link-failure
   Last reconfirmed|                            |2020-04-21
             Status|UNCONFIRMED                 |NEW

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
That function is intentionally not defined, and only used in unevaluated
contexts.

It seems to come from the sortable constraint on next_permutation, because
commenting out the requires-clause fixes the link failure:

    template<bidirectional_range _Range, typename _Comp =3D ranges::less,
             typename _Proj =3D identity>
      requires sortable<iterator_t<_Range>, _Comp, _Proj>

The sortable concept uses projected as a template argument to another conce=
pt:

  template<typename _Iter, typename _Rel =3D ranges::less,
           typename _Proj =3D identity>
    concept sortable =3D permutable<_Iter>
      && indirect_strict_weak_order<_Rel, projected<_Iter, _Proj>>;

That ends up being used with this constrained alias template:

  template<__detail::__dereferenceable _Tp>
    requires requires(_Tp& __t)
    { { ranges::iter_move(__t) } -> __detail::__can_reference; }
    using iter_rvalue_reference_t
      =3D decltype(ranges::iter_move(std::declval<_Tp&>()));

Which uses:

  namespace ranges
  {
    namespace __cust_imove
    {
      void iter_move();

      template<typename _Tp>
        concept __adl_imove
          =3D (std::__detail::__class_or_enum<remove_reference_t<_Tp>>)
          && requires(_Tp&& __t) { iter_move(static_cast<_Tp&&>(__t)); };

      struct _IMove
      {
        // [...]

        template<typename _Tp>
          requires __adl_imove<_Tp> || requires(_Tp& __e) { *__e; }
          constexpr decltype(auto)
          operator()(_Tp&& __e) const
          // noexcept([...])
          {
            if constexpr (__adl_imove<_Tp>)
              return iter_move(static_cast<_Tp&&>(__e));
            else if constexpr (is_reference_v<iter_reference_t<_Tp>>)
              return std::move(*__e);
            else
              return *__e;
          }
      };
    } // namespace __cust_imove

    inline namespace __cust
    {
      inline constexpr __cust_imove::_IMove iter_move{};
    } // inline namespace __cust
  } // namespace ranges


So it appears that determining the return type of that function in an
unevaluated context causes its instantiation to be kept, leaving a referenc=
e to
the undefined projected::operator*() function.

We might be able to avoid using return type deduction for _IMove::operator()
but I wonder if this is really a compiler bug. I imagine this same problem
could occur for other uses of return type deduction.=