[Bug libstdc++/96042] Reference type of std::ranges::iota is __int128 with -std=c++2a?!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96042 --- Comment #11 from CVS Commits --- The releases/gcc-10 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:12042aeb9336f20b9225b2e5139e5f6c9bde7642 commit r10-9021-g12042aeb9336f20b9225b2e5139e5f6c9bde7642 Author: Jonathan Wakely Date: Fri Nov 13 13:04:10 2020 + 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 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.
[Bug libstdc++/96042] Reference type of std::ranges::iota is __int128 with -std=c++2a?!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96042 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Jonathan Wakely --- Done for 10.3
[Bug libstdc++/96042] Reference type of std::ranges::iota is __int128 with -std=c++2a?!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96042 --- Comment #9 from CVS Commits --- The releases/gcc-10 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:a65261443a9b9cfac876c0b7e47393587eb1ce5c commit r10-9015-ga65261443a9b9cfac876c0b7e47393587eb1ce5c Author: Jonathan Wakely 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 libstdc++-v3/ChangeLog: 2020-08-19 Jonathan Wakely Patrick Palka PR libstdc++/96042 * include/bits/range_access.h (__detail::__to_unsigned_like): Do not use make_unsigned_t in the return type, as it can result in an error before the integral 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?!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96042 --- Comment #8 from CVS Commits --- The releases/gcc-10 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:8eb9a45e87bdb81cb44948c651edee846c622a0f commit r10-9014-g8eb9a45e87bdb81cb44948c651edee846c622a0f Author: Jonathan Wakely 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): 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?!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96042 --- Comment #7 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:e6e01618e83bcd9eb3a2b27df30ed87106a748b4 commit r11-2773-ge6e01618e83bcd9eb3a2b27df30ed87106a748b4 Author: Jonathan Wakely 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 libstdc++-v3/ChangeLog: 2020-08-19 Jonathan Wakely Patrick Palka PR libstdc++/96042 * include/bits/range_access.h (__detail::__to_unsigned_like): Do not use make_unsigned_t in the return type, as it can result in an error before the integral 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?!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96042 --- Comment #6 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:386fd16c551188e20d5b1684b7139e4269f9a739 commit r11-2766-g386fd16c551188e20d5b1684b7139e4269f9a739 Author: Jonathan Wakely 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): Define. * testsuite/std/ranges/iota/96042.cc: New test.
[Bug libstdc++/96042] Reference type of std::ranges::iota is __int128 with -std=c++2a?!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96042 Jonathan Wakely 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?!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96042 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2020-07-07 Status|RESOLVED|REOPENED Ever confirmed|0 |1 Resolution|INVALID |--- --- Comment #5 from Jonathan Wakely --- 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?!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96042 TC changed: What|Removed |Added CC||rs2740 at gmail dot com --- Comment #4 from TC --- 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?!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96042 --- Comment #3 from Jonathan Wakely --- (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. > > 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. > 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. 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. 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 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?!
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. 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. 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?!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96042 Jonathan Wakely changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from Jonathan Wakely --- 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 or numeric_limits::is_specialized is true for the difference type of iota_view.
