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