[Bug libstdc++/111357] New: __integer_pack fails to work with values of dependent type convertible to integers

["frankhb1989 at gmail dot com" <gcc-bugzilla@gcc.gnu.org>]

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

            Bug ID: 111357
           Summary: __integer_pack fails to work with values of dependent
                    type convertible to integers
           Product: gcc
           Version: 13.1.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: frankhb1989 at gmail dot com
  Target Milestone: ---

Case:

#include <cstddef>
#include <type_traits>
#include <tuple>

using std::size_t;
#if __cpp_lib_integer_sequence >= 201304L
using std::index_sequence;
using std::make_index_sequence;
#else
template<size_t... V>
struct index_sequence
{};

template<class>
struct succ;

template<size_t... V>
struct succ<index_sequence<V...>>
{
        using type = index_sequence<V..., sizeof...(V)>;
};

template<size_t N>
struct iseq
{
        using type = typename succ<typename iseq<N - 1>::type>::type;
};

template<>
struct iseq<0>
{
        using type = index_sequence<>;
};

template<size_t N>
using make_index_sequence = typename iseq<N>::type;
#endif


template<size_t... V>
void g(index_sequence<V...>)
{}

template<typename T>
struct R
{
        using S = make_index_sequence<std::tuple_size<std::tuple<T>>{}>;

        R() noexcept(noexcept(g(S())))
        {}
};

int main()
{
        R<int>();
}


Output of x86-64 gcc 13.2 (Compiler #1)
<source>: In instantiation of 'R<T>::R() [with T = int]':
<source>:55:9:   required from here
<source>:49:33: error: argument to '__integer_pack' must be between 0 and
268435452
   49 |         R() noexcept(noexcept(g(S())))
      |                                 ^~~

This should work as -std=c++11 which uses a naive implementation of
make_index_sequence here.

I mark it as a libstdc++ bug of conformance for the case. The root cause seems
a bug of the implementation in the frontend, but I'm not that sure, because the
document of __integer_pack does not mention such cases explicitly. (The error
message here is obviously confusing, though.)