* [libstdc++] Inconsistent detection of __int128 @ 2021-01-04 0:43 David Edelsohn 2021-01-04 2:45 ` Jonathan Wakely 0 siblings, 1 reply; 8+ messages in thread From: David Edelsohn @ 2021-01-04 0:43 UTC (permalink / raw) To: Jonathan Wakely; +Cc: libstdc++, Iain Sandoe, CHIGOT, CLEMENT TL;DR: Change libstdc++ to uniformly use __SIZEOF_INT128__ to detect __int128 and remove the definition detected by configure. Some libstdc++ headers check for __int128 by directly testing __SIZEOF_INT128__ and other headers test for _GLIBCXX_USE_INT128. __GLIBCXX_USE_INT128 is probed during libstdc++ configuration phase. * std/charconv:#if _GLIBCXX_USE_INT128 std/limits:#elif defined __STRICT_ANSI__ && defined __SIZEOF_INT128__ std/ranges:#ifdef __SIZEOF_INT128__ std/ranges: else if constexpr (__SIZEOF_INT128__ > sizeof(_Wp)) bits/c++config:#ifdef __SIZEOF_INT128__ bits/iterator_concepts.h:#if defined __STRICT_ANSI__ && defined __SIZEOF_INT128__ bits/iterator_concepts.h:#if __SIZEOF_INT128__ bits/iterator_concepts.h:#if __SIZEOF_INT128__ bits/max_size_type.h:#if __SIZEOF_INT128__ bits/max_size_type.h:#if __SIZEOF_INT128__ * bits/random.h:#ifdef _GLIBCXX_USE_INT128 bits/ranges_base.h:#if defined __STRICT_ANSI__ && defined __SIZEOF_INT128__ bits/uniform_int_dist.h:#if __SIZEOF_INT128__ libstdc++ headers also depend on __float128 and use _GLIBCXX_USE_FLOAT128, but the value is defined dynamically in c++config.h: /* Define if __float128 is supported on this host. */ #if defined(__FLOAT128__) || defined(__SIZEOF_FLOAT128__) #define _GLIBCXX_USE_FLOAT128 1 #endif The GLIBXX_USE_INT128 situation is a problem for AIX, Darwin and other platforms that are trying to convert to FAT libraries, where both 32 bit and 64 bit libraries are in the same location. When GCC looks for libraries in the same location, it also wants to look for header files in the same location. Almost all libstdc++ header files are architecture or bitsize agonostic, with the differences localized in c++config.h. The configure-time definition of _GLIBCXX_USE_INT128 generates a gratuitous difference in the contents of c++config.h that otherwise could use the same file. As a first step to make __int128 usage consistent within libstdc++ headers, I propose that libstdc++ configure not define _GLIBCXX_USE_INT128 and bits/c++config instead dynamically test for __SIZEOF_INT128__ /* Define if __int128 is supported on this host. */ #ifdef __SIZEOF_INT128__ #define _GLIBCXX_USE_INT128 1 #endif Alternatively, uses of _GLIBCXX_USE_INT128 could be changed to __SIZEOF_INT128__ and remove all references to _GLIBCXX_USE_INT128. In which direction would the community like to transition? Or is there some other reason that _GLIBCXX_USE_INT128 and __SIZEOF_INT128__ are used in different contexts? Thanks, David ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [libstdc++] Inconsistent detection of __int128 2021-01-04 0:43 [libstdc++] Inconsistent detection of __int128 David Edelsohn @ 2021-01-04 2:45 ` Jonathan Wakely 2021-01-04 3:26 ` David Edelsohn 0 siblings, 1 reply; 8+ messages in thread From: Jonathan Wakely @ 2021-01-04 2:45 UTC (permalink / raw) To: David Edelsohn; +Cc: Jonathan Wakely, libstdc++, Iain Sandoe, CHIGOT, CLEMENT On Mon, 4 Jan 2021, 00:44 David Edelsohn via Libstdc++, < libstdc++@gcc.gnu.org> wrote: > > Or is there some other reason that _GLIBCXX_USE_INT128 and > __SIZEOF_INT128__ are used in different contexts? > Yes. I'll reply when I'm back from taking some time off. Probably Wednesday. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [libstdc++] Inconsistent detection of __int128 2021-01-04 2:45 ` Jonathan Wakely @ 2021-01-04 3:26 ` David Edelsohn 2021-01-08 16:09 ` Jonathan Wakely 0 siblings, 1 reply; 8+ messages in thread From: David Edelsohn @ 2021-01-04 3:26 UTC (permalink / raw) To: Jonathan Wakely; +Cc: Jonathan Wakely, libstdc++, Iain Sandoe, CHIGOT, CLEMENT On Sun, Jan 3, 2021 at 9:45 PM Jonathan Wakely <jwakely.gcc@gmail.com> wrote: > > On Mon, 4 Jan 2021, 00:44 David Edelsohn via Libstdc++, <libstdc++@gcc.gnu.org> wrote: >> >> Or is there some other reason that _GLIBCXX_USE_INT128 and >> __SIZEOF_INT128__ are used in different contexts? > > Yes. > > I'll reply when I'm back from taking some time off. Probably Wednesday. If the uses of _GLIBCXX_USE_INT128 in libstdc++ headers specifically are checking if __int128 type is different than "long" and "long long", as opposed to the availability of the __int128, can c++config.h define _GLIBCXX_USE_INT128 by comparing __SIZEOF_INT128__ to __SIZEOF_LONG_LONG__ and __SIZEOF_LONG__ instead of the libstdc++ configure template typename test? I'll wait until your back from PTO for an answer. Thanks, David ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [libstdc++] Inconsistent detection of __int128 2021-01-04 3:26 ` David Edelsohn @ 2021-01-08 16:09 ` Jonathan Wakely 2021-01-08 20:00 ` David Edelsohn 2021-04-30 20:24 ` David Edelsohn 0 siblings, 2 replies; 8+ messages in thread From: Jonathan Wakely @ 2021-01-08 16:09 UTC (permalink / raw) To: David Edelsohn; +Cc: Jonathan Wakely, libstdc++, Iain Sandoe, CHIGOT, CLEMENT [-- Attachment #1: Type: text/plain, Size: 1750 bytes --] On 03/01/21 22:26 -0500, David Edelsohn via Libstdc++ wrote: >On Sun, Jan 3, 2021 at 9:45 PM Jonathan Wakely <jwakely.gcc@gmail.com> wrote: >> >> On Mon, 4 Jan 2021, 00:44 David Edelsohn via Libstdc++, <libstdc++@gcc.gnu.org> wrote: >>> >>> Or is there some other reason that _GLIBCXX_USE_INT128 and >>> __SIZEOF_INT128__ are used in different contexts? >> >> Yes. >> >> I'll reply when I'm back from taking some time off. Probably Wednesday. > >If the uses of _GLIBCXX_USE_INT128 in libstdc++ headers specifically >are checking if __int128 type is different than "long" and "long >long", as opposed to the availability of the __int128, can c++config.h Yes, the test is not just "is __int128 a valid type?" but "should we use __int128 as a larger integer type?" We used to use it more widely, but many places that use __int128 conditionally now check __GLIBCXX_INT_N_0 instead, because that is defined when __int128 is available and we're not compiling in a "strict ansi" dialect. Of the two remaining uses of _GLIBCXX_USE_INT128 I think one is wrong and should test __SIZEOF__INT128__ directly. We specifically do want to use unsigned __int128 in __to_chars_unsigned_type even if it's the same as a standard type. So that leaves one remaining use, and I think that should do as you suggest here ... >define _GLIBCXX_USE_INT128 by comparing __SIZEOF_INT128__ to >__SIZEOF_LONG_LONG__ and __SIZEOF_LONG__ instead of the libstdc++ >configure template typename test? Yes, that seems fine. But since we only need it in one place, let's just do that test in that one place. It makes the purpose of the test more explicit, and so you don't need to look up what _GLIBCXX_USE_INT128 means and when it's true. Does the attached patch work for you? [-- Attachment #2: patch.txt --] [-- Type: text/x-patch, Size: 3079 bytes --] diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4 index e4175ea3e64..33ac1e0c46c 100644 --- a/libstdc++-v3/acinclude.m4 +++ b/libstdc++-v3/acinclude.m4 @@ -3106,15 +3106,14 @@ EOF ]) dnl -dnl Check for GNU 128-bit integer and floating point types. +dnl Check for GNU 128-bit floating point type. dnl -dnl Note: also checks that the types aren't standard types. +dnl Note: also checks that the type isn't a standard type. dnl dnl Defines: -dnl _GLIBCXX_USE_INT128 dnl ENABLE_FLOAT128 dnl -AC_DEFUN([GLIBCXX_ENABLE_INT128_FLOAT128], [ +AC_DEFUN([GLIBCXX_ENABLE_FLOAT128], [ AC_LANG_SAVE AC_LANG_CPLUSPLUS @@ -3122,34 +3121,7 @@ AC_DEFUN([GLIBCXX_ENABLE_INT128_FLOAT128], [ # Fake what AC_TRY_COMPILE does, without linking as this is # unnecessary for this test. - cat > conftest.$ac_ext << EOF -[#]line __oline__ "configure" -template<typename T1, typename T2> - struct same - { typedef T2 type; }; - -template<typename T> - struct same<T, T>; - -int main() -{ - typename same<long, __int128>::type i1; - typename same<long long, __int128>::type i2; -} -EOF - - AC_MSG_CHECKING([for __int128]) - if AC_TRY_EVAL(ac_compile); then - AC_DEFINE(_GLIBCXX_USE_INT128, 1, - [Define if __int128 is supported on this host.]) - enable_int128=yes - else - enable_int128=no - fi - AC_MSG_RESULT($enable_int128) - rm -f conftest* - - cat > conftest.$ac_ext << EOF + cat > conftest.$ac_ext << EOF [#]line __oline__ "configure" template<typename T1, typename T2> diff --git a/libstdc++-v3/configure.ac b/libstdc++-v3/configure.ac index 3c799be82b1..7eed93d0f04 100644 --- a/libstdc++-v3/configure.ac +++ b/libstdc++-v3/configure.ac @@ -153,7 +153,7 @@ GLIBCXX_ENABLE_THREADS GLIBCXX_ENABLE_ATOMIC_BUILTINS GLIBCXX_ENABLE_LOCK_POLICY GLIBCXX_ENABLE_DECIMAL_FLOAT -GLIBCXX_ENABLE_INT128_FLOAT128 +GLIBCXX_ENABLE_FLOAT128 if test "$enable_float128" = yes; then port_specific_symbol_files="$port_specific_symbol_files \$(top_srcdir)/config/abi/pre/float128.ver" fi diff --git a/libstdc++-v3/include/bits/random.h b/libstdc++-v3/include/bits/random.h index 32537f80df7..7d13ac1b430 100644 --- a/libstdc++-v3/include/bits/random.h +++ b/libstdc++-v3/include/bits/random.h @@ -99,7 +99,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION struct _Select_uint_least_t<__s, 2> { typedef unsigned long long type; }; -#ifdef _GLIBCXX_USE_INT128 +#if __SIZEOF_INT128__ > __SIZEOF_LONG_LONG__ template<int __s> struct _Select_uint_least_t<__s, 1> { typedef unsigned __int128 type; }; diff --git a/libstdc++-v3/include/std/charconv b/libstdc++-v3/include/std/charconv index b57b0a16db2..fd622a02629 100644 --- a/libstdc++-v3/include/std/charconv +++ b/libstdc++-v3/include/std/charconv @@ -93,7 +93,7 @@ namespace __detail struct __to_chars_unsigned_type : __make_unsigned_selector_base { using _UInts = _List<unsigned int, unsigned long, unsigned long long -#if _GLIBCXX_USE_INT128 +#ifdef __SIZEOF_INT128__ , unsigned __int128 #endif >; ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [libstdc++] Inconsistent detection of __int128 2021-01-08 16:09 ` Jonathan Wakely @ 2021-01-08 20:00 ` David Edelsohn 2021-04-30 20:24 ` David Edelsohn 1 sibling, 0 replies; 8+ messages in thread From: David Edelsohn @ 2021-01-08 20:00 UTC (permalink / raw) To: Jonathan Wakely; +Cc: Jonathan Wakely, libstdc++, Iain Sandoe, CHIGOT, CLEMENT On Fri, Jan 8, 2021 at 11:10 AM Jonathan Wakely <jwakely@redhat.com> wrote: > > On 03/01/21 22:26 -0500, David Edelsohn via Libstdc++ wrote: > >On Sun, Jan 3, 2021 at 9:45 PM Jonathan Wakely <jwakely.gcc@gmail.com> wrote: > >> > >> On Mon, 4 Jan 2021, 00:44 David Edelsohn via Libstdc++, <libstdc++@gcc.gnu.org> wrote: > >>> > >>> Or is there some other reason that _GLIBCXX_USE_INT128 and > >>> __SIZEOF_INT128__ are used in different contexts? > >> > >> Yes. > >> > >> I'll reply when I'm back from taking some time off. Probably Wednesday. > > > >If the uses of _GLIBCXX_USE_INT128 in libstdc++ headers specifically > >are checking if __int128 type is different than "long" and "long > >long", as opposed to the availability of the __int128, can c++config.h > > Yes, the test is not just "is __int128 a valid type?" but "should we > use __int128 as a larger integer type?" > > We used to use it more widely, but many places that use __int128 > conditionally now check __GLIBCXX_INT_N_0 instead, because that is > defined when __int128 is available and we're not compiling in a > "strict ansi" dialect. > > Of the two remaining uses of _GLIBCXX_USE_INT128 I think one is wrong > and should test __SIZEOF__INT128__ directly. We specifically do want > to use unsigned __int128 in __to_chars_unsigned_type even if it's the > same as a standard type. > > So that leaves one remaining use, and I think that should do as you > suggest here ... > > >define _GLIBCXX_USE_INT128 by comparing __SIZEOF_INT128__ to > >__SIZEOF_LONG_LONG__ and __SIZEOF_LONG__ instead of the libstdc++ > >configure template typename test? > > Yes, that seems fine. But since we only need it in one place, let's > just do that test in that one place. It makes the purpose of the test > more explicit, and so you don't need to look up what > _GLIBCXX_USE_INT128 means and when it's true. > > Does the attached patch work for you? Hi, Jonathan Thanks for carefully investigating this further. This cleanup and patch look good from an AIX-perspective. It definitely clarifies the purpose and it's good to remove gratuitous differences and unnecessary macros. Thanks, David ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [libstdc++] Inconsistent detection of __int128 2021-01-08 16:09 ` Jonathan Wakely 2021-01-08 20:00 ` David Edelsohn @ 2021-04-30 20:24 ` David Edelsohn 2021-05-04 11:12 ` Jonathan Wakely 1 sibling, 1 reply; 8+ messages in thread From: David Edelsohn @ 2021-04-30 20:24 UTC (permalink / raw) To: Jonathan Wakely; +Cc: Jonathan Wakely, libstdc++, Iain Sandoe, CHIGOT, CLEMENT On Fri, Jan 8, 2021 at 11:10 AM Jonathan Wakely <jwakely@redhat.com> wrote: > > On 03/01/21 22:26 -0500, David Edelsohn via Libstdc++ wrote: > >On Sun, Jan 3, 2021 at 9:45 PM Jonathan Wakely <jwakely.gcc@gmail.com> wrote: > >> > >> On Mon, 4 Jan 2021, 00:44 David Edelsohn via Libstdc++, <libstdc++@gcc.gnu.org> wrote: > >>> > >>> Or is there some other reason that _GLIBCXX_USE_INT128 and > >>> __SIZEOF_INT128__ are used in different contexts? > >> > >> Yes. > >> > >> I'll reply when I'm back from taking some time off. Probably Wednesday. > > > >If the uses of _GLIBCXX_USE_INT128 in libstdc++ headers specifically > >are checking if __int128 type is different than "long" and "long > >long", as opposed to the availability of the __int128, can c++config.h > > Yes, the test is not just "is __int128 a valid type?" but "should we > use __int128 as a larger integer type?" > > We used to use it more widely, but many places that use __int128 > conditionally now check __GLIBCXX_INT_N_0 instead, because that is > defined when __int128 is available and we're not compiling in a > "strict ansi" dialect. > > Of the two remaining uses of _GLIBCXX_USE_INT128 I think one is wrong > and should test __SIZEOF__INT128__ directly. We specifically do want > to use unsigned __int128 in __to_chars_unsigned_type even if it's the > same as a standard type. > > So that leaves one remaining use, and I think that should do as you > suggest here ... > > >define _GLIBCXX_USE_INT128 by comparing __SIZEOF_INT128__ to > >__SIZEOF_LONG_LONG__ and __SIZEOF_LONG__ instead of the libstdc++ > >configure template typename test? > > Yes, that seems fine. But since we only need it in one place, let's > just do that test in that one place. It makes the purpose of the test > more explicit, and so you don't need to look up what > _GLIBCXX_USE_INT128 means and when it's true. > > Does the attached patch work for you? Hi, Jonathan Thanks for pushing the INT64_T patch. I tested your revised patch in January and it works perfectly. Could you push your INT128 patch to trunk when you have a moment? Thanks, David ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [libstdc++] Inconsistent detection of __int128 2021-04-30 20:24 ` David Edelsohn @ 2021-05-04 11:12 ` Jonathan Wakely 2021-05-04 13:53 ` David Edelsohn 0 siblings, 1 reply; 8+ messages in thread From: Jonathan Wakely @ 2021-05-04 11:12 UTC (permalink / raw) To: David Edelsohn; +Cc: libstdc++, Iain Sandoe, CHIGOT, CLEMENT, gcc-patches [-- Attachment #1: Type: text/plain, Size: 2614 bytes --] On 30/04/21 16:24 -0400, David Edelsohn via Libstdc++ wrote: >On Fri, Jan 8, 2021 at 11:10 AM Jonathan Wakely <jwakely@redhat.com> wrote: >> >> On 03/01/21 22:26 -0500, David Edelsohn via Libstdc++ wrote: >> >On Sun, Jan 3, 2021 at 9:45 PM Jonathan Wakely <jwakely.gcc@gmail.com> wrote: >> >> >> >> On Mon, 4 Jan 2021, 00:44 David Edelsohn via Libstdc++, <libstdc++@gcc.gnu.org> wrote: >> >>> >> >>> Or is there some other reason that _GLIBCXX_USE_INT128 and >> >>> __SIZEOF_INT128__ are used in different contexts? >> >> >> >> Yes. >> >> >> >> I'll reply when I'm back from taking some time off. Probably Wednesday. >> > >> >If the uses of _GLIBCXX_USE_INT128 in libstdc++ headers specifically >> >are checking if __int128 type is different than "long" and "long >> >long", as opposed to the availability of the __int128, can c++config.h >> >> Yes, the test is not just "is __int128 a valid type?" but "should we >> use __int128 as a larger integer type?" >> >> We used to use it more widely, but many places that use __int128 >> conditionally now check __GLIBCXX_INT_N_0 instead, because that is >> defined when __int128 is available and we're not compiling in a >> "strict ansi" dialect. >> >> Of the two remaining uses of _GLIBCXX_USE_INT128 I think one is wrong >> and should test __SIZEOF__INT128__ directly. We specifically do want >> to use unsigned __int128 in __to_chars_unsigned_type even if it's the >> same as a standard type. >> >> So that leaves one remaining use, and I think that should do as you >> suggest here ... >> >> >define _GLIBCXX_USE_INT128 by comparing __SIZEOF_INT128__ to >> >__SIZEOF_LONG_LONG__ and __SIZEOF_LONG__ instead of the libstdc++ >> >configure template typename test? >> >> Yes, that seems fine. But since we only need it in one place, let's >> just do that test in that one place. It makes the purpose of the test >> more explicit, and so you don't need to look up what >> _GLIBCXX_USE_INT128 means and when it's true. >> >> Does the attached patch work for you? > >Hi, Jonathan > >Thanks for pushing the INT64_T patch. > >I tested your revised patch in January and it works perfectly. > >Could you push your INT128 patch to trunk when you have a moment? > >Thanks, David I've pushed the attached to trunk after testing on powerpc-aix and x86_64-linux. Contrary to what I said in January, I think both sues of _GLIBCXX_USE_INT128 do want to only use __int128 if it's larger than long long. For __to_chars_unsigned_type there's no point trying to use unsigned __int128 if it's the same size as unsigned long long, because we'd already have chosen unsigned long long. [-- Attachment #2: patch.txt --] [-- Type: text/x-patch, Size: 4215 bytes --] commit ad0a3be4df5eecc79075d899fd79179d0f61270e Author: Jonathan Wakely <jwakely@redhat.com> Date: Tue May 4 12:07:09 2021 libstdc++: Remove _GLIBCXX_USE_INT128 autoconf macro We don't need to decide whether to use __int128 when running configure, we can do so at compilation time by seeing if __SIZEOF_INT128__ is defined and if it's greater than __SIZEOF_LONG_LONG__. This removes another unnecessary architecture-specific config macro in <bits/c++config.h>, so the same header can work for 32-bit or 64-bit compilation on AIX. libstdc++-v3/ChangeLog: * acinclude.m4 (GLIBCXX_ENABLE_INT128_FLOAT128): Remove checks for __int128 and rename to GLIBCXX_ENABLE_FLOAT128. * config.h.in: Regenerate. * configure: Regenerate. * configure.ac: Adjust to use GLIBCXX_ENABLE_FLOAT128. * include/bits/random.h (_Select_uint_least_t<s, 1>): Use __SIZEOF_INT128__ to decide whether to use __int128. * include/std/charconv (__to_chars_unsigned_type): Likewise. diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4 index 7b78e148fbd..94897a654c9 100644 --- a/libstdc++-v3/acinclude.m4 +++ b/libstdc++-v3/acinclude.m4 @@ -3049,15 +3049,14 @@ EOF ]) dnl -dnl Check for GNU 128-bit integer and floating point types. +dnl Check for GNU 128-bit floating point type. dnl -dnl Note: also checks that the types aren't standard types. +dnl Note: also checks that the type isn't a standard types. dnl dnl Defines: -dnl _GLIBCXX_USE_INT128 dnl ENABLE_FLOAT128 dnl -AC_DEFUN([GLIBCXX_ENABLE_INT128_FLOAT128], [ +AC_DEFUN([GLIBCXX_ENABLE_FLOAT128], [ AC_LANG_SAVE AC_LANG_CPLUSPLUS @@ -3065,34 +3064,7 @@ AC_DEFUN([GLIBCXX_ENABLE_INT128_FLOAT128], [ # Fake what AC_TRY_COMPILE does, without linking as this is # unnecessary for this test. - cat > conftest.$ac_ext << EOF -[#]line __oline__ "configure" -template<typename T1, typename T2> - struct same - { typedef T2 type; }; - -template<typename T> - struct same<T, T>; - -int main() -{ - typename same<long, __int128>::type i1; - typename same<long long, __int128>::type i2; -} -EOF - - AC_MSG_CHECKING([for __int128]) - if AC_TRY_EVAL(ac_compile); then - AC_DEFINE(_GLIBCXX_USE_INT128, 1, - [Define if __int128 is supported on this host.]) - enable_int128=yes - else - enable_int128=no - fi - AC_MSG_RESULT($enable_int128) - rm -f conftest* - - cat > conftest.$ac_ext << EOF + cat > conftest.$ac_ext << EOF [#]line __oline__ "configure" template<typename T1, typename T2> struct same diff --git a/libstdc++-v3/configure.ac b/libstdc++-v3/configure.ac index 95dd9ce5da5..a816ff79d16 100644 --- a/libstdc++-v3/configure.ac +++ b/libstdc++-v3/configure.ac @@ -153,7 +153,7 @@ GLIBCXX_ENABLE_THREADS GLIBCXX_ENABLE_ATOMIC_BUILTINS GLIBCXX_ENABLE_LOCK_POLICY GLIBCXX_ENABLE_DECIMAL_FLOAT -GLIBCXX_ENABLE_INT128_FLOAT128 +GLIBCXX_ENABLE_FLOAT128 if test "$enable_float128" = yes; then port_specific_symbol_files="$port_specific_symbol_files \$(top_srcdir)/config/abi/pre/float128.ver" fi diff --git a/libstdc++-v3/include/bits/random.h b/libstdc++-v3/include/bits/random.h index 1b9cc5f16a9..0da013c5f45 100644 --- a/libstdc++-v3/include/bits/random.h +++ b/libstdc++-v3/include/bits/random.h @@ -99,7 +99,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION struct _Select_uint_least_t<__s, 2> { typedef unsigned long long type; }; -#ifdef _GLIBCXX_USE_INT128 +#if __SIZEOF_INT128__ > __SIZEOF_LONG_LONG__ template<int __s> struct _Select_uint_least_t<__s, 1> { typedef unsigned __int128 type; }; diff --git a/libstdc++-v3/include/std/charconv b/libstdc++-v3/include/std/charconv index 6e407f31e30..193702e677a 100644 --- a/libstdc++-v3/include/std/charconv +++ b/libstdc++-v3/include/std/charconv @@ -94,7 +94,7 @@ namespace __detail struct __to_chars_unsigned_type : __make_unsigned_selector_base { using _UInts = _List<unsigned int, unsigned long, unsigned long long -#if _GLIBCXX_USE_INT128 +#if __SIZEOF_INT128__ > __SIZEOF_LONG_LONG__ , unsigned __int128 #endif >; ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [libstdc++] Inconsistent detection of __int128 2021-05-04 11:12 ` Jonathan Wakely @ 2021-05-04 13:53 ` David Edelsohn 0 siblings, 0 replies; 8+ messages in thread From: David Edelsohn @ 2021-05-04 13:53 UTC (permalink / raw) To: Jonathan Wakely; +Cc: libstdc++, Iain Sandoe, CHIGOT, CLEMENT, GCC Patches On Tue, May 4, 2021 at 7:12 AM Jonathan Wakely <jwakely@redhat.com> wrote: > > On 30/04/21 16:24 -0400, David Edelsohn via Libstdc++ wrote: > >On Fri, Jan 8, 2021 at 11:10 AM Jonathan Wakely <jwakely@redhat.com> wrote: > >> > >> On 03/01/21 22:26 -0500, David Edelsohn via Libstdc++ wrote: > >> >On Sun, Jan 3, 2021 at 9:45 PM Jonathan Wakely <jwakely.gcc@gmail.com> wrote: > >> >> > >> >> On Mon, 4 Jan 2021, 00:44 David Edelsohn via Libstdc++, <libstdc++@gcc.gnu.org> wrote: > >> >>> > >> >>> Or is there some other reason that _GLIBCXX_USE_INT128 and > >> >>> __SIZEOF_INT128__ are used in different contexts? > >> >> > >> >> Yes. > >> >> > >> >> I'll reply when I'm back from taking some time off. Probably Wednesday. > >> > > >> >If the uses of _GLIBCXX_USE_INT128 in libstdc++ headers specifically > >> >are checking if __int128 type is different than "long" and "long > >> >long", as opposed to the availability of the __int128, can c++config.h > >> > >> Yes, the test is not just "is __int128 a valid type?" but "should we > >> use __int128 as a larger integer type?" > >> > >> We used to use it more widely, but many places that use __int128 > >> conditionally now check __GLIBCXX_INT_N_0 instead, because that is > >> defined when __int128 is available and we're not compiling in a > >> "strict ansi" dialect. > >> > >> Of the two remaining uses of _GLIBCXX_USE_INT128 I think one is wrong > >> and should test __SIZEOF__INT128__ directly. We specifically do want > >> to use unsigned __int128 in __to_chars_unsigned_type even if it's the > >> same as a standard type. > >> > >> So that leaves one remaining use, and I think that should do as you > >> suggest here ... > >> > >> >define _GLIBCXX_USE_INT128 by comparing __SIZEOF_INT128__ to > >> >__SIZEOF_LONG_LONG__ and __SIZEOF_LONG__ instead of the libstdc++ > >> >configure template typename test? > >> > >> Yes, that seems fine. But since we only need it in one place, let's > >> just do that test in that one place. It makes the purpose of the test > >> more explicit, and so you don't need to look up what > >> _GLIBCXX_USE_INT128 means and when it's true. > >> > >> Does the attached patch work for you? > > > >Hi, Jonathan > > > >Thanks for pushing the INT64_T patch. > > > >I tested your revised patch in January and it works perfectly. > > > >Could you push your INT128 patch to trunk when you have a moment? > > > >Thanks, David > > I've pushed the attached to trunk after testing on powerpc-aix and > x86_64-linux. > > Contrary to what I said in January, I think both sues of > _GLIBCXX_USE_INT128 do want to only use __int128 if it's larger than > long long. For __to_chars_unsigned_type there's no point trying to use > unsigned __int128 if it's the same size as unsigned long long, because > we'd already have chosen unsigned long long. Hi, Jonathan Excellent. Thank you very much for addressing this issue and removing the multilib size dependencies in libstdc++ headers. Thanks, David ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2021-05-04 13:53 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-01-04 0:43 [libstdc++] Inconsistent detection of __int128 David Edelsohn 2021-01-04 2:45 ` Jonathan Wakely 2021-01-04 3:26 ` David Edelsohn 2021-01-08 16:09 ` Jonathan Wakely 2021-01-08 20:00 ` David Edelsohn 2021-04-30 20:24 ` David Edelsohn 2021-05-04 11:12 ` Jonathan Wakely 2021-05-04 13:53 ` David Edelsohn
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).