| Message ID | 20191011155009.GA20051@redhat.com |
|---|---|
| State | New |
| Headers | show |
| Series | Use __is_same_as for std::is_same and std::is_same_v | expand |
Le ven. 11 oct. 2019 à 17:50, Jonathan Wakely <jwakely@redhat.com> a écrit : > > By using the built-in we don't need to match a partial specialization > for std::is_same and don't need to instantiate std::is_same at all for > uses of std::is_same_v. > > * include/std/type_traits (is_same): Replace partial specialization > by using __is_same_as built-in in primary template. > (is_same_v): Use __is_same_as built-in instead of instantiating the > is_same trait. > > Tested x86_64-linux, committed to trunk. > Hi Jonathan, It looks like this creates the following error when I try to bootstrap clang 9.0.0 using the latest gcc and libstdc++ from trunk. Note that with g++, there is no problem, however it looks like clang++ has some problem with the new header. I don't know if this is an issue on libstdc++ side or clang++ side. Cheers, Romain FAILED: compiler-rt/lib/xray/CMakeFiles/RTXray.x86_64.dir/xray_buffer_queue.cc.o /workdir/build/final-system/llvm-build/./bin/clang++ --target=x86_64-1a-linux-gnu -DXRAY_HAS_EXCEPTIONS=1 -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I/workdir/src/llvm-9.0.0/compiler-rt/lib/xray/.. -I/workdir/src/llvm-9.0.0/compiler-rt/lib/xray/../../include -O2 -msse -msse2 -msse3 -I/workdir/build/final-system/llvm-temporary-static-dependencies/install/include -I/workdir/build/final-system/llvm-temporary-static-dependencies/install/include/ncursesw -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -std=c++11 -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wstring-conversion -fdiagnostics-color -ffunction-sections -fdata-sections -Wall -std=c++11 -Wno-unused-parameter -O3 -DNDEBUG -m64 -fPIC -fno-builtin -fno-exceptions -fomit-frame-pointer -funwind-tables -fno-stack-protector -fno-sanitize=safe-stack -fvisibility=hidden -fno-lto -O3 -gline-tables-only -Wno-gnu -Wno-variadic-macros -Wno-c99-extensions -Wno-non-virtual-dtor -fno-rtti -MD -MT compiler-rt/lib/xray/CMakeFiles/RTXray.x86_64.dir/xray_buffer_queue.cc.o -MF compiler-rt/lib/xray/CMakeFiles/RTXray.x86_64.dir/xray_buffer_queue.cc.o.d -o compiler-rt/lib/xray/CMakeFiles/RTXray.x86_64.dir/xray_buffer_queue.cc.o -c /workdir/src/llvm-9.0.0/compiler-rt/lib/xray/xray_buffer_queue.cc In file included from /workdir/src/llvm-9.0.0/compiler-rt/lib/xray/xray_buffer_queue.cc:21: In file included from /workdir/src/llvm-9.0.0/compiler-rt/lib/xray/xray_allocator.h:29: In file included from /workdir/src/llvm-9.0.0/compiler-rt/lib/xray/xray_utils.h:20: In file included from /opt/1A/toolchain/x86_64-v20.0.3/lib64/gcc/x86_64-1a-linux-gnu/10.0.0/../../../../include/c++/10.0.0/utility:70: In file included from /opt/1A/toolchain/x86_64-v20.0.3/lib64/gcc/x86_64-1a-linux-gnu/10.0.0/../../../../include/c++/10.0.0/bits/stl_pair.h:59: In file included from /opt/1A/toolchain/x86_64-v20.0.3/lib64/gcc/x86_64-1a-linux-gnu/10.0.0/../../../../include/c++/10.0.0/bits/move.h:55: /opt/1A/toolchain/x86_64-v20.0.3/lib64/gcc/x86_64-1a-linux-gnu/10.0.0/../../../../include/c++/10.0.0/type_traits:1393:51: error: '_Tp' does not refer to a value : public integral_constant<bool, __is_same_as(_Tp, _Up)> ^ /opt/1A/toolchain/x86_64-v20.0.3/lib64/gcc/x86_64-1a-linux-gnu/10.0.0/../../../../include/c++/10.0.0/type_traits:1391:21: note: declared here template<typename _Tp, typename _Up> ^ /opt/1A/toolchain/x86_64-v20.0.3/lib64/gcc/x86_64-1a-linux-gnu/10.0.0/../../../../include/c++/10.0.0/type_traits:1393:56: error: '_Up' does not refer to a value : public integral_constant<bool, __is_same_as(_Tp, _Up)> ^ /opt/1A/toolchain/x86_64-v20.0.3/lib64/gcc/x86_64-1a-linux-gnu/10.0.0/../../../../include/c++/10.0.0/type_traits:1391:35: note: declared here template<typename _Tp, typename _Up> ^ 2 errors generated.
Le sam. 12 oct. 2019 à 17:44, Romain Geissler <romain.geissler@gmail.com> a écrit : > > It looks like this creates the following error when I try to bootstrap > clang 9.0.0 using the latest gcc and libstdc++ from trunk. Note that > with g++, there is no problem, however it looks like clang++ has some > problem with the new header. I don't know if this is an issue on > libstdc++ side or clang++ side. __is_same_as is not implemented as a compiler builtin in clang++ unlike g++, thus the error on clang 9.0.0 side. It looks like current clang trunk doesn't define __is_same_as either. Until clang implements this support (if it ever will), usage of __is_same_as in libstdc++ shall be conditional, only when __has_builtin(__is_same_as) is true (however that would require that gcc implements __has_builtin, as implemented here: https://gcc.gnu.org/ml/gcc-patches/2019-10/msg00062.html ) Cheers, Romain
On 12/10/19 18:15 +0200, Romain Geissler wrote: >Le sam. 12 oct. 2019 à 17:44, Romain Geissler ><romain.geissler@gmail.com> a écrit : >> >> It looks like this creates the following error when I try to bootstrap >> clang 9.0.0 using the latest gcc and libstdc++ from trunk. Note that >> with g++, there is no problem, however it looks like clang++ has some >> problem with the new header. I don't know if this is an issue on >> libstdc++ side or clang++ side. > >__is_same_as is not implemented as a compiler builtin in clang++ Sigh, I guess that explains why we weren't using it already. >unlike g++, thus the error on clang 9.0.0 side. It looks like current >clang trunk doesn't define __is_same_as either. Until clang implements >this support (if it ever will), usage of __is_same_as in libstdc++ >shall be conditional, only when __has_builtin(__is_same_as) is true >(however that would require that gcc implements __has_builtin, as >implemented here: >https://gcc.gnu.org/ml/gcc-patches/2019-10/msg00062.html ) No, we don't need GCC to support __has_builtin, because we know GCC supports __is_same_as so there's no need to check for it. So something like this would work fine: #if __GNUC__ >= 10 # define _GLIBCXX_HAVE__IS_SAME_AS #elif defined(__has_builtin) # if __has_builtin(__is_same_as) # define _GLIBCXX_HAVE__IS_SAME_AS # endif #endif
On 16/10/19 10:42 +0100, Jonathan Wakely wrote: >On 12/10/19 18:15 +0200, Romain Geissler wrote: >>Le sam. 12 oct. 2019 à 17:44, Romain Geissler >><romain.geissler@gmail.com> a écrit : >>> >>>It looks like this creates the following error when I try to bootstrap >>>clang 9.0.0 using the latest gcc and libstdc++ from trunk. Note that >>>with g++, there is no problem, however it looks like clang++ has some >>>problem with the new header. I don't know if this is an issue on >>>libstdc++ side or clang++ side. >> >>__is_same_as is not implemented as a compiler builtin in clang++ > >Sigh, I guess that explains why we weren't using it already. > >>unlike g++, thus the error on clang 9.0.0 side. It looks like current >>clang trunk doesn't define __is_same_as either. Until clang implements >>this support (if it ever will), usage of __is_same_as in libstdc++ >>shall be conditional, only when __has_builtin(__is_same_as) is true >>(however that would require that gcc implements __has_builtin, as >>implemented here: >>https://gcc.gnu.org/ml/gcc-patches/2019-10/msg00062.html ) > >No, we don't need GCC to support __has_builtin, because we know GCC >supports __is_same_as so there's no need to check for it. > >So something like this would work fine: > >#if __GNUC__ >= 10 ># define _GLIBCXX_HAVE__IS_SAME_AS >#elif defined(__has_builtin) ># if __has_builtin(__is_same_as) ># define _GLIBCXX_HAVE__IS_SAME_AS ># endif >#endif It looks like Clang provides __is_same instead. I'll commit a fix today.
On 16/10/19 10:43 +0100, Jonathan Wakely wrote: >On 16/10/19 10:42 +0100, Jonathan Wakely wrote: >>On 12/10/19 18:15 +0200, Romain Geissler wrote: >>>Le sam. 12 oct. 2019 à 17:44, Romain Geissler >>><romain.geissler@gmail.com> a écrit : >>>> >>>>It looks like this creates the following error when I try to bootstrap >>>>clang 9.0.0 using the latest gcc and libstdc++ from trunk. Note that >>>>with g++, there is no problem, however it looks like clang++ has some >>>>problem with the new header. I don't know if this is an issue on >>>>libstdc++ side or clang++ side. >>> >>>__is_same_as is not implemented as a compiler builtin in clang++ >> >>Sigh, I guess that explains why we weren't using it already. >> >>>unlike g++, thus the error on clang 9.0.0 side. It looks like current >>>clang trunk doesn't define __is_same_as either. Until clang implements >>>this support (if it ever will), usage of __is_same_as in libstdc++ >>>shall be conditional, only when __has_builtin(__is_same_as) is true >>>(however that would require that gcc implements __has_builtin, as >>>implemented here: >>>https://gcc.gnu.org/ml/gcc-patches/2019-10/msg00062.html ) >> >>No, we don't need GCC to support __has_builtin, because we know GCC >>supports __is_same_as so there's no need to check for it. >> >>So something like this would work fine: >> >>#if __GNUC__ >= 10 >># define _GLIBCXX_HAVE__IS_SAME_AS >>#elif defined(__has_builtin) >># if __has_builtin(__is_same_as) >># define _GLIBCXX_HAVE__IS_SAME_AS >># endif >>#endif > >It looks like Clang provides __is_same instead. > >I'll commit a fix today. This is what I've committed to trunk, after testing on x86_64-linux, and checking it with Clang. Thanks for testing and reporting the problem.
diff --git a/libstdc++-v3/include/std/type_traits b/libstdc++-v3/include/std/type_traits index dc8a019324d..4de5daa9f06 100644 --- a/libstdc++-v3/include/std/type_traits +++ b/libstdc++-v3/include/std/type_traits @@ -1388,13 +1388,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION // Type relations. /// is_same - template<typename, typename> + template<typename _Tp, typename _Up> struct is_same - : public false_type { }; - - template<typename _Tp> - struct is_same<_Tp, _Tp> - : public true_type { }; + : public integral_constant<bool, __is_same_as(_Tp, _Up)> + { }; /// is_base_of template<typename _Base, typename _Derived> @@ -3158,7 +3155,7 @@ template <typename _Tp> template <typename _Tp, unsigned _Idx = 0> inline constexpr size_t extent_v = extent<_Tp, _Idx>::value; template <typename _Tp, typename _Up> - inline constexpr bool is_same_v = is_same<_Tp, _Up>::value; + inline constexpr bool is_same_v = __is_same_as(_Tp, _Up); template <typename _Base, typename _Derived> inline constexpr bool is_base_of_v = is_base_of<_Base, _Derived>::value; template <typename _From, typename _To>
By using the built-in we don't need to match a partial specialization for std::is_same and don't need to instantiate std::is_same at all for uses of std::is_same_v. * include/std/type_traits (is_same): Replace partial specialization by using __is_same_as built-in in primary template. (is_same_v): Use __is_same_as built-in instead of instantiating the is_same trait. Tested x86_64-linux, committed to trunk. commit ee208e530893aeb12b6a9edb1563a4e8ecaea887 Author: Jonathan Wakely <jwakely@redhat.com> Date: Wed Sep 11 21:23:31 2019 +0100 Use __is_same_as for std::is_same and std::is_same_v By using the built-in we don't need to match a partial specialization for std::is_same and don't need to instantiate std::is_same at all for uses of std::is_same_v. * include/std/type_traits (is_same): Replace partial specialization by using __is_same_as built-in in primary template. (is_same_v): Use __is_same_as built-in instead of instantiating the is_same trait.