https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121097
Bug ID: 121097
Summary: hypot uses __promoted_t even when
__cpp_fold_expressions is not defined
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: arthur.j.odwyer at gmail dot com
Target Milestone: ---
libstdc++'s <ext/type_traits.h> defines __gnu_cxx::__promoted_t if and only if
__cpp_fold_expressions is defined by the compiler:
#if __cpp_fold_expressions
template<typename... _Tp>
using __promoted_t = decltype((typename __promote<_Tp>::__type(0) +
...));
But libstdc++'s <cmath> tries to use that functionality on all compilers whose
__cplusplus claims C++17 support:
#ifdef __cpp_lib_hypot // C++ >= 17 && HOSTED
[...]
template<typename _Tp, typename _Up, typename _Vp>
__gnu_cxx::__promoted_t<_Tp, _Up, _Vp>
hypot(_Tp __x, _Up __y, _Vp __z)
Therefore there is an obscure subset of compiler implementations -- those that
set __cplusplus to 201703 but don't define __cpp_fold_expressions -- for which
libstdc++'s <cmath> produces this error spew:
/usr/include/c++/11/cmath:1880 error 5649: no template named '__promoted_t' in
namespace '__gnu_cxx'
/usr/include/c++/11/cmath:1883 error 5649: no template named '__promoted_t' in
namespace '__gnu_cxx'
/usr/include/c++/11/cmath:1884 error 40: undeclared identifier '__type'
The example in front of me right now is PCLint 2.0 (November 2022). Now, we're
also stuck on libstdc++ 11.4, so we're going to have to work around this on our
end anyway (by manually -D__cpp_fold_expressions=201603 on our PC-Lint command
line). But IMHO you should still want to harmonize these macros on your end:
either define your __promoted_t more liberally in <ext/type_traits.h>, or else
define the three-argument hypot() more conservatively in <cmath>.
