Implement numeric_limits<__float128>.
Marc Glisse
marc.glisse@inria.fr
Sat May 11 03:38:00 GMT 2019
On Fri, 10 May 2019, Ed Smith-Rowland via libstdc++ wrote:
> I know people are mostly looking at release branch work but I'd like to post
> this. Other projects like mppp and boost use our __float128 with C++. I use
> it for specfun testing and various other projects. I'd like to offer a series
> of patches to enable this support straight from libstdc++. This is the first
> patch. Next will be <cmath> and then <complex> a bit later.
>
> It's pretty straightforward but others might have tips on configuration (and
> anything else ;-)). Built and tested of x86_64-linux.
+# define FLT128_MAX 1.18973149535723176508575932662800702e4932Q
+# define FLT128_MIN 3.36210314311209350626267781732175260e-4932Q
etc
do such names really belong in <limits>?
I see that the preprocessor has macros
#define __FLT128_MAX__ 1.18973149535723176508575932662800702e+4932F128
#define __FLT128_MIN__ 3.36210314311209350626267781732175260e-4932F128
for type _Float128 but the C++ compiler does not know that type or
operator""F128. It seems broken that the compiler defines the macro for
something it does not support. Having FLT128_MIN and __FLT128_MIN__ refer
to different things seems like a bad idea. If you define
__STDC_WANT_IEC_60559_TYPES_EXT__ and include <float.h> you already get
FLT128_MIN as _Float128 and if you include <quadmath.h> you already get
FLT128_MIN as __float128 (and if you do both in this order you get a
redefinition warning with -Wsystem-headers).
--
Marc Glisse
More information about the Libstdc++
mailing list