Ensure cpp_double_float128 elm-func tests run in CI

[ckormanyos]

No description provided.

[ckormanyos]

See also #171

[ckormanyos]

Hi @jzmaddock and @mborland, I got stuck here.

In this project, we support

cpp_double_fp_backend<::boost::float128_type>

but only in the presence of

BOOST_HAS_FLOAT128

but this requires non-strict ANSI (such as with -std=g++20 or similar on GCC). In other words, you need !defined(__STRICT_ANSI__) in order to get BOOST_HAS_FLOAT128. See this line way back in the compiler-configurations.

That seems to me to be consistent with how other MP backends use 128-bit float (with the exception of float128.hpp).

OK, so when you have BOOST_HAS_FLOAT128, you also get convenient support of __float128 in <limits> and in <type_traits>. I can handle that and it makes things a lot easier.

My question is How do I run CI and ensure that BOOST_HAS_FLOAT128 is defined? I'm not really that good at bjam/b2, and I am unable to see in Multiprecision's CI exactly if we do or do not have any -std=gnu++14, 20, etc. runs (with the -gnu-part).

So how can I run CI with the Jamfile and really be sure that I have BOOST_HAS_FLOAT128?

Cc: @sinandredemption and @cosurgi

[cosurgi]

Is it possible to see how the tests in CI perform the testing of the ::boost::float128_type ?

[ckormanyos]

Is it possible to see how the tests in CI perform the testing of the ::boost::float128_type ?

Hey, that's a good idea @cosurgi. It seems, however, like there is no such testing.

The 128-bit testing seems like it might use backends::float128_backend, which was the originally first 128-bit wrappper from John.

[ckormanyos]

The 128-bit testing seems like it might use backends::float128_backend, which was the originally first 128-bit wrappper from John.

And backends::float128_backend does interoperate with strict ANSI. So those tests just work with stuff like -std=c++20, etc.

[cosurgi]

So maybe do the tests when #ifdef BOOST_HAS_FLOAT128 and skip them when it is not available?

[ckormanyos]

So maybe do the tests when #ifdef BOOST_HAS_FLOAT128 and skip them when it is not available?

No. Actually, #ifdef BOOST_HAS_FLOAT128 is the wrong query, and the answer is simple. It is much easier than I had realized when initially starting the query in this thread. I just did not get it until this post.

We should certainly support the double-128-bit type if native __float128 or Intel's _Quad is available. And this support should exist regardless of whether ANSI is strict or not.

Pathway:

Most of the needed PP-stuff and wrappers are already there. I can simply use (or make up a new) PP-switch indicating that the type is available. The tiny amount of <type_traits>, <limits> and <cmath>-style functions are mostly already hanging around in Boost-MP.

Summary:

• If __float128 or _Quad can be detected, then support cpp_double_float128 and of course its full tests in CI.

Cc: @jzmaddock and @cosurgi and @sinandredemption

[ckormanyos]

Did I ever mention that, ... somewhere on my long (and growing) TODO list is to make generic IEEE-754 compatible (software) float128 for those compilers not having it?

Will I/we ever get to it? Cc: @mborland

[jzmaddock]

The GNU enabled tests are run on drone, and the strict ANSI tests on Github.

The float128 backend should be strict-ansi compatible and somewhat tested now, but I believe the full tests are only run in GNU mode. It might be possible to fix the tests in ANSI mode as well, but I haven't looked.

[ckormanyos]

The GNU enabled tests are run on drone, and the strict ANSI tests on Github.

Thanks John, I Got it

The float128 backend should be strict-ansi compatible and somewhat tested now, but I believe the full tests are only run in GNU mode. It might be possible to fix the tests in ANSI mode as well, but I haven't looked.

I'm convinced that the best thing to do is make cpp_double_float128 be ANSI/gnu++ agnostic. So this question will simply ... dissolve. I'll pull in/write whatever we need for that. it's rather straightforward.

We can review all this when it shakes out in code.

[ckormanyos]

I'm convinced that the best thing to do is make cpp_double_float128 be ANSI/gnu++ agnostic. So this question will simply ... dissolve. I'll pull in/write whatever we need for that. it's rather straightforward.

I tried for a week or so to get this but ultimately did not get it entirely correct.

So i will revert to:

• Support cpp_couble_fp_backend<::boost::float128_type> in -std=gnuXX modes only.

In a future step, I might consider to use ANSI-compatible float128.hpp. But for the moment, I'll simply ensure that the GUN-mode compatible stuff works and is well-tested.

[ckormanyos]

Fixed by #173