[Bug libstdc++/94679] New: link time error: undefined reference to std::projected<...>::operator *() const

[Bug libstdc++/94679] New: link time error: undefined reference to std::projected<...>::operator *() const

[okannen at gmail dot com]

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

            Bug ID: 94679
           Summary: link time error: undefined reference to
                    std::projected<...>::operator *() const
           Product: gcc
           Version: 10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: okannen at gmail dot com
  Target Milestone: ---
              Host: x86_64-pc-linux-gnu
            Target: x86_64
             Build: x86_64-pc-linux-gnu

When compiling with -coverage -fkeep-inline-functions, it is possible to get a
linkage error: 'undefined reference to
`std::projected<int*,std::identity>::operator*() const'


gcc --version:
gcc (GCC) 10.0.1 20200416 (experimental)
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

gcc -v:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/olivier/usr/libexec/gcc/x86_64-pc-linux-gnu/10/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --enable-libsanitizer
--prefix=/home/olivier/usr/ --with-gcc-major-version-only --disable-bootstrap
--enable-language=c,c++,lto
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.0.1 20200416 (experimental) (GCC)


The following code compiled with:
'c++ -coverage -fkeep-inline-functions -std=c++20 file.cpp'

#include <algorithm>
int main(){
  int a[]={1,2,3};
  std::ranges::next_permutation(a);
  return 0;
  }

This produce error message:
/usr/bin/ld: /tmp/ccF8BXBM.o: in function `decltype(auto)
std::ranges::__cust_imove::_IMove::operator()<std::projected<int*,
std::identity>&>(std::projected<int*, std::identity>&) const':
test.cpp:(.text._ZNKSt6ranges12__cust_imove6_IMoveclIRSt9projectedIPiSt8identityEEEDcOT_[_ZNKSt6ranges12__cust_imove6_IMoveclIRSt9projectedIPiSt8identityEEEDcOT_]+0x2a):
undefined reference to `std::projected<int*, std::identity>::operator*() const'
/usr/bin/ld: /tmp/ccF8BXBM.o: in function `decltype(auto)
std::ranges::__cust_imove::_IMove::operator()<std::projected<int*,
std::identity> const&>(std::projected<int*, std::identity> const&) const':
test.cpp:(.text._ZNKSt6ranges12__cust_imove6_IMoveclIRKSt9projectedIPiSt8identityEEEDcOT_[_ZNKSt6ranges12__cust_imove6_IMoveclIRKSt9projectedIPiSt8identityEEEDcOT_]+0x2a):
undefined reference to `std::projected<int*, std::identity>::operator*() const'
collect2: error: ld returned 1 exit status

[Bug c++/94679] link time error: undefined reference to std::projected<...>::operator *() const

[redi at gcc dot gnu.org]

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

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 = ranges::less,
             typename _Proj = identity>
      requires sortable<iterator_t<_Range>, _Comp, _Proj>

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

  template<typename _Iter, typename _Rel = ranges::less,
           typename _Proj = identity>
    concept sortable = 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
      = decltype(ranges::iter_move(std::declval<_Tp&>()));

Which uses:

  namespace ranges
  {
    namespace __cust_imove
    {
      void iter_move();

      template<typename _Tp>
        concept __adl_imove
          = (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 reference 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.

[Bug c++/94679] link time error: undefined reference to std::projected<...>::operator *() const

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Reduced:

template<typename T>
struct projected
{
  T operator*() const;
};

struct IMove
{
  template<typename T>
    decltype(auto)
    operator()(T&& t) const
    {
      return *t;
    }
};

IMove iter_move;

template<typename T>
concept fooable = requires (T t) { iter_move(t); };

template<typename T>
requires fooable<projected<T>>
void func(T)
{
}

int main()
{
  int i = 0;
  func(i);
}


g++ -std=c++20  use.cc -coverage -fkeep-inline-functions
/usr/bin/ld: /tmp/ccS2FlMR.o: in function `decltype(auto)
IMove::operator()<projected<int>&>(projected<int>&) const':
/tmp/use.cc:13: undefined reference to `projected<int>::operator*() const'
collect2: error: ld returned 1 exit status

[Bug c++/94679] link time error: undefined reference to std::projected<...>::operator *() const

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I suspect -fkeep-inline-functions is not really usable any more with C++ code
like this.
To make sure fooable constraint is valid, we need to instantiate
"IMove::operator()" which we don't know if it is going to be used later on or
not.  Since it is inline (implicitly), -fkeep-inline-functions will keep it
around and "IMove::operator()" calls "projected<int>::operator*() const"