Open seanxnie opened 10 months ago
Does the issue persist if you build with -std=gnu++20
instead of -std=c++20
?
Does the issue persist if you build with
-std=gnu++20
instead of-std=c++20
?
Yes, the issue is solved. This is to enable gnu extensions in c++20. Thank you!
Just to confirm, that float128.hpp does indeed require gnu++XX not c++-XX, it should be documented somewhere...
Just to confirm, that float128.hpp does indeed require gnu++XX not c++-XX, it should be documented somewhere...
As far as my findings from boost.org and pdfs, requiring gnu++XX in float128 is not documented.
I think you're right actually, I dimly remember removing that restriction, hence the use of quad_min/quad_max rather than Q suffixed constants. Will investigate further...
hence the use of quad_min/quad_max rather than Q suffixed constants. Will investigate further...
Ummm, I'm not the expert here, but I think what the -std=gnuXX
language extensions do is add numeric_limits
support and the quad-suffixes. I'm not sure if anything else is added.
I'm almost certain that the fundamental support of libquadmath
is available in c++
-standards.
Check it at Godbolt.
Admittedly, __float128
has been a long-time source of confusion for me personally. And I've made a few mistakes down that road with assumptioins...
My example was not nice. Here is a better one.
OK, so here's the issue... we used to rely on Q suffixed constants for numeric_limits support, those were removed so that's all good. The issue here is convertibility... float128 is only explicitly convertible to type number when building with c++XX rather than gnu++XX.... and the reason for that is that float128 is not an arithmetic type (according to
So either.... we change the convertibility rules so that float128 is always treated as an arithmetic type, or I just add some explicit casts to the numeric_Limits functions. The former seems more logical, but messes up the enable_if logic if we have to treat float128 as a special case.
I also have a hunch that we're not testing any of this, so the testing logic needs looking at too...
OK, so here's the issue... we used to rely on Q suffixed constants for numeric_limits support, those were removed so that's all good. The issue here is convertibility... float128 is only explicitly convertible to type number when building with c++XX rather than gnu++XX.... and the reason for that is that float128 is not an arithmetic type (according to
) when building with c++XX.... and we have a general rule in place that "arithmetic types are always implicitly convertible, everything else is only explicitly convertible and only if the backend has a suitable constructor". So either.... we change the convertibility rules so that float128 is always treated as an arithmetic type, or I just add some explicit casts to the numeric_Limits functions. The former seems more logical, but messes up the enable_if logic if we have to treat float128 as a special case.
I also have a hunch that we're not testing any of this, so the testing logic needs looking at too...
As a note the specializations of numeric_limits is changing in GCC 14: https://github.com/boostorg/math/issues/992. I am not sure off hand if that is the case for
__float128
is not an arithmetic type
Oh yes. That was one of the other things that is enabled by -std=gnu++XX
as opposed to -std=c++XX
. The former (GNU) also supports __float128
as a built-in type in the sense of <type_traits>
.
We need a list somewhere reminding what does and does not happen to __float128
in GNU/non-GNU.
This program showcases what is available for __float128
when using -std=gnu++XX
.
Dear all. I just encountered an issue when compiling the following code, which is to invoke the
boost::math::expm1
function.The command line for compiling code is:
The compiler error output is considerable. However, the main issue is
max min
type conversion:In above code, this issue will disappear if replacing
float128
bympfr_float_50
. Theboost::multiprecision
I used is the latest development version. The error happens whenever a math function needs to invokemax min
offloat128
. It seems that a bug exists infloat128.hpp
in boost. I hope the information above is enough to find the issue. Thanks a lot.Sean