[Bug libstdc++/96042] New: Reference type of std::ranges::iota is __int128 with -std=c++2a?!

[Bug libstdc++/96042] New: Reference type of std::ranges::iota is __int128 with -std=c++2a?!

[gcc-bugs at marehr dot dialup.fu-berlin.de]

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

            Bug ID: 96042
           Summary: Reference type of std::ranges::iota is __int128 with
                    -std=c++2a?!
           Product: gcc
           Version: 10.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: gcc-bugs at marehr dot dialup.fu-berlin.de
  Target Milestone: ---

The following code

```c++
#include <ranges>

using iota_view = std::ranges::iota_view<size_t>;
using reference_t = std::ranges::range_difference_t<iota_view>;

static_assert(std::same_as<reference_t, __int128>); // why?

// but std::numeric_limits is not specialised which indicates that we use
__STRICT_ANSI__

using t = std::numeric_limits<__int128>;
static_assert(t::is_specialized);
```

https://godbolt.org/z/-XFyYN

I don't fully understand what `__int128` and `__STRICT_ANSI__` means, but I
think it is unexpected that I get a type that is not described in the standard.

I know that `std::indirectly_readable` allows (compiler) implementation defined
signed integer types, but from what I have seen, `__int128` is normally only
supported / exposed in the gnu standard library if `__STRICT_ANSI__` is not
defined.

Since `-std=c++2a` does not provide a specialisation for `std::numeric_limits`,
I assume that this means, that `__STRICT_ANSI__` is not defined in that mode,
and I think this is inconsistent behaviour.

Related issues in the range-v3 library:
* https://github.com/ericniebler/range-v3/issues/1514
* https://github.com/ericniebler/range-v3/issues/1516

[Bug libstdc++/96042] Reference type of std::ranges::iota is __int128 with -std=c++2a?!

[redi at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Not a bug.

When __STRICT_ANSI__ is defined is_integral_v<__int128> is false and
numeric_limits<__int128> is not specialized.

But that doesn't matter, because the difference type of iota_view does not have
to be a standard integer type. __int128 is a valid type for the difference type
of iota_view. There is no requirement that is_integral_v<ID> or
numeric_limits<ID>::is_specialized is true for the difference type of
iota_view.

[Bug libstdc++/96042] Reference type of std::ranges::iota is __int128 with -std=c++2a?!

[gcc-bugs at marehr dot dialup.fu-berlin.de]

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

--- Comment #2 from gcc-bugs at marehr dot dialup.fu-berlin.de ---
I think this is too easy to say that this is not a "bug", we can also weaken
the terminology and say "potential-inconsistency".

Technically you are right, but only because there seems to be a specific
"exception" for the implementation does not mean that this is the right thing
to do.

<unhappy-end-user - ignore this>
I personally don't understand why the standard allows exceptions outside it's
echo-system, I guess the stdlib implementers understand the subject better when
forming the standard, and are lobbing harder for their necessities which is
sometimes different from the needs / expectation of the end-user.
</unhappy-end-user- ignore this>

Can you help me figure out in which cases `-std=c++2a` would produce this type?
Or asked differently: In which cases, other than this, do I encounter a
`__int128` from using only types and functions defined in the standard?

I have the feeling from your answer that this type is an everyday type.

Looking at https://eel.is/c++draft/range.iota#view-1, and if I read it
correctly, this is case 3:

> Otherwise, IOTA-DIFF-T(W) is an unspecified signed-integer-like type
> ([iterator.concept.winc]) of width not less than the width of W.
> 
> [Note: It is unspecified whether this type satisfies
> weakly_­incrementable. — end note]

It means it would be totally fine to return the signed version of `size_t`,
because it has at least the same width. (This would be a valid option, too)

Thank you for your time!

[Bug libstdc++/96042] Reference type of std::ranges::iota is __int128 with -std=c++2a?!

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to gcc-bugs from comment #2)
> I think this is too easy to say that this is not a "bug", we can also weaken
> the terminology and say "potential-inconsistency".
> 
> Technically you are right, but only because there seems to be a specific
> "exception" for the implementation does not mean that this is the right
> thing to do.

I disagree. In the strongest possible terms.

> <unhappy-end-user - ignore this>
> I personally don't understand why the standard allows exceptions outside
> it's echo-system, I guess the stdlib implementers understand the subject
> better when forming the standard, and are lobbing harder for their
> necessities which is sometimes different from the needs / expectation of the
> end-user.
> </unhappy-end-user- ignore this>

This has nothing to do with our own necessities, this is to support end users.

> Can you help me figure out in which cases `-std=c++2a` would produce this
> type? Or asked differently: In which cases, other than this, do I encounter
> a `__int128` from using only types and functions defined in the standard?

I'm not aware of any others currently. That could change in future if the C and
C++ standards are changed to allow types larger than long long to be treated as
standard integer types. I would be very happy to see the ideas described in
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2425.pdf happen.

> I have the feeling from your answer that this type is an everyday type.

No. It's not, and that's exactly why we used it for IOTA-DIFF-T.

> Looking at https://eel.is/c++draft/range.iota#view-1, and if I read it
> correctly, this is case 3:
> 
> > Otherwise, IOTA-DIFF-T(W) is an unspecified signed-integer-like type
> > ([iterator.concept.winc]) of width not less than the width of W.
> > 
> > [Note: It is unspecified whether this type satisfies
> > weakly_­incrementable. — end note]
> 
> It means it would be totally fine to return the signed version of `size_t`,
> because it has at least the same width. (This would be a valid option, too)

But it wouldn't be totally fine, because that type (i.e. ptrdiff_t) cannot
represent the difference between the begin and end iterators of
iota_view<size_t, SIZE_MAX>.

The whole point of allowing IOTA-DIFF-T to be an unspecified integer-like type
is to solve that problem. It has to be a type larger than size_t, otherwise you
can't use large iota_view types, and that make a different group of users
unhappy.

Our implementation will soon be updated to use a custom class type that behaves
like an integer, so that we can also represent the maximum difference for
iota_view<unsigned __int128, (unsigned __int128)-1>. Will you still complain
that "it is unexpected that I get a type that is not described in the
standard"? 

It's **not possible** to represent the difference type of iota_view<W,B> for
every W without using a type that isn't in the set of types allowed for W. See
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1522r1.pdf for the
background.

Why is using __int128 here a problem? Do you really think we should treat "I am
surprised by this" as a more serious concern than "Some specializations of
iota_view have undefined bhaviour because the alternative would surprise some
people"?

You being unhappy because you don't expect something can (I hope) be resolved
by explaining the pragmatic engineering reasons behind the decision. Some code
being impossible to write cannot really be explained just by saying "we know
how to make this work, but it made somebody sad so we decided not to support
it, sorry".

The problem here seems to be that you expect the difference type of an
iota_view to be a normal integer type. Your expectation is wrong. You should
change your expectation.

[Bug libstdc++/96042] Reference type of std::ranges::iota is __int128 with -std=c++2a?!

[rs2740 at gmail dot com]

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

TC <rs2740 at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rs2740 at gmail dot com

--- Comment #4 from TC <rs2740 at gmail dot com> ---
Note that https://wg21.link/iterator.concept.winc#10 requires numeric_limits
specializations for integer-class types.

[Bug libstdc++/96042] Reference type of std::ranges::iota is __int128 with -std=c++2a?!

[redi at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2020-07-07
             Status|RESOLVED                    |REOPENED
     Ever confirmed|0                           |1
         Resolution|INVALID                     |---

--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Thanks, Tim. So we need to expose the int128 specializations even for strict
modes. I think that's still conforming as long as is_integral remains false.

That change will be needed on gcc-10 branch even after we stop using __int128
on trunk.

[Bug libstdc++/96042] Reference type of std::ranges::iota is __int128 with -std=c++2a?!

[redi at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |redi at gcc dot gnu.org
             Status|REOPENED                    |ASSIGNED
   Target Milestone|---                         |10.3

[Bug libstdc++/96042] Reference type of std::ranges::iota is __int128 with -std=c++2a?!

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 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:386fd16c551188e20d5b1684b7139e4269f9a739

commit r11-2766-g386fd16c551188e20d5b1684b7139e4269f9a739
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Wed Aug 19 16:27:25 2020 +0100

    libstdc++: Make __int128 meet integer-class requirements [PR 96042]

    Because __int128 can be used as the difference type for iota_view, we
    need to ensure that it meets the requirements of an integer-class type.
    The requirements in [iterator.concept.winc] p10 include numeric_limits
    being specialized and giving meaningful answers. Currently we only
    specialize numeric_limits for non-standard integer types in non-strict
    modes.  However, nothing prevents us from defining an explicit
    specialization for any implementation-defined type, so it doesn't matter
    whether std::is_integral<__int128> is true or not.

    This patch ensures that the numeric_limits specializations for signed
    and unsigned __int128 are defined whenever __int128 is available. It
    also makes the __numeric_traits and __int_limits helpers work for
    __int128, via a new __gnu_cxx::__is_integer_nonstrict trait.

    libstdc++-v3/ChangeLog:

            PR libstdc++/96042
            * include/ext/numeric_traits.h (__is_integer_nonstrict): New
            trait which is true for 128-bit integers even in strict modes.
            (__numeric_traits_integer, __numeric_traits): Use
            __is_integer_nonstrict instead of __is_integer.
            * include/std/limits [__STRICT_ANSI__ && __SIZEOF_INT128__]
            (numeric_limits<__int128>, (numeric_limits<unsigned __int128>):
            Define.
            * testsuite/std/ranges/iota/96042.cc: New test.

[Bug libstdc++/96042] Reference type of std::ranges::iota is __int128 with -std=c++2a?!

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 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:e6e01618e83bcd9eb3a2b27df30ed87106a748b4

commit r11-2773-ge6e01618e83bcd9eb3a2b27df30ed87106a748b4
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Wed Aug 19 20:36:10 2020 +0100

    libstdc++: Make make-unsigned-like-t<__int128> work [PR 96042]

    As well as ensuring that numeric_limits<__int128> is defined, we need to
    ensure that make-unsigned-like-t and to-unsigned-like work correctly for
    128-bit integers in strict mode. This ensures that a subrange created
    from an iota_view's iterator and sentinel can represent its size.

    Co-authored-by: Patrick Palka  <ppalka@redhat.com>

    libstdc++-v3/ChangeLog:

    2020-08-19  Jonathan Wakely  <jwakely@redhat.com>
                Patrick Palka  <ppalka@redhat.com>

            PR libstdc++/96042
            * include/bits/range_access.h (__detail::__to_unsigned_like):
            Do not use make_unsigned_t<T> in the return type, as it can
            result in an error before the integral<T> constraint is checked.
            [__STRICT_ANSI__]: Add overloads for 128-bit integer types.
            (__detail::__make_unsigned_like_t): Define as the return type
            of __to_unsigned_like.
            * testsuite/std/ranges/subrange/96042.cc: New test.

[Bug libstdc++/96042] Reference type of std::ranges::iota is __int128 with -std=c++2a?!

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:8eb9a45e87bdb81cb44948c651edee846c622a0f

commit r10-9014-g8eb9a45e87bdb81cb44948c651edee846c622a0f
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Wed Aug 19 16:27:25 2020 +0100

    libstdc++: Make __int128 meet integer-class requirements [PR 96042]

    Because __int128 can be used as the difference type for iota_view, we
    need to ensure that it meets the requirements of an integer-class type.
    The requirements in [iterator.concept.winc] p10 include numeric_limits
    being specialized and giving meaningful answers. Currently we only
    specialize numeric_limits for non-standard integer types in non-strict
    modes.  However, nothing prevents us from defining an explicit
    specialization for any implementation-defined type, so it doesn't matter
    whether std::is_integral<__int128> is true or not.

    This patch ensures that the numeric_limits specializations for signed
    and unsigned __int128 are defined whenever __int128 is available. It
    also makes the __numeric_traits and __int_limits helpers work for
    __int128, via a new __gnu_cxx::__is_integer_nonstrict trait.

    libstdc++-v3/ChangeLog:

            PR libstdc++/96042
            * include/ext/numeric_traits.h (__is_integer_nonstrict): New
            trait which is true for 128-bit integers even in strict modes.
            (__numeric_traits_integer, __numeric_traits): Use
            __is_integer_nonstrict instead of __is_integer.
            * include/std/limits [__STRICT_ANSI__ && __SIZEOF_INT128__]
            (numeric_limits<__int128>, (numeric_limits<unsigned __int128>):
            Define.
            * testsuite/std/ranges/iota/96042.cc: New test.

    (cherry picked from commit 386fd16c551188e20d5b1684b7139e4269f9a739)

[Bug libstdc++/96042] Reference type of std::ranges::iota is __int128 with -std=c++2a?!

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r10-9015-ga65261443a9b9cfac876c0b7e47393587eb1ce5c
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Wed Aug 19 20:36:10 2020 +0100

    libstdc++: Make make-unsigned-like-t<__int128> work [PR 96042]

    As well as ensuring that numeric_limits<__int128> is defined, we need to
    ensure that make-unsigned-like-t and to-unsigned-like work correctly for
    128-bit integers in strict mode. This ensures that a subrange created
    from an iota_view's iterator and sentinel can represent its size.

    Co-authored-by: Patrick Palka  <ppalka@redhat.com>

    libstdc++-v3/ChangeLog:

    2020-08-19  Jonathan Wakely  <jwakely@redhat.com>
                Patrick Palka  <ppalka@redhat.com>

            PR libstdc++/96042
            * include/bits/range_access.h (__detail::__to_unsigned_like):
            Do not use make_unsigned_t<T> in the return type, as it can
            result in an error before the integral<T> constraint is checked.
            [__STRICT_ANSI__]: Add overloads for 128-bit integer types.
            (__detail::__make_unsigned_like_t): Define as the return type
            of __to_unsigned_like.
            * testsuite/std/ranges/subrange/96042.cc: New test.

    (cherry picked from commit e6e01618e83bcd9eb3a2b27df30ed87106a748b4)

[Bug libstdc++/96042] Reference type of std::ranges::iota is __int128 with -std=c++2a?!

[redi at gcc dot gnu.org]

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

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

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

--- Comment #10 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Done for 10.3

[Bug libstdc++/96042] Reference type of std::ranges::iota is __int128 with -std=c++2a?!

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:12042aeb9336f20b9225b2e5139e5f6c9bde7642

commit r10-9021-g12042aeb9336f20b9225b2e5139e5f6c9bde7642
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Fri Nov 13 13:04:10 2020 +0000

    libstdc++: Fix test that fails for targets without __int128 [PR 96042]

    When backporting this test (and the changes it depends on) I forgot that
    the __max_diff_type and __max_size_type classes are only present on
    trunk, not the gcc-10 branch. That using iota_view<long long, long long>
    oonly works correctly when __int128 is available, so the test fails on
    32-bit targets.

    This just skips the failing check.

            PR libstdc++/96042
            * testsuite/std/ranges/iota/96042.cc: Only assert that the
            difference type is wider than long long if __int128 is
            supported.