Rework frexp as per #1329

[ckormanyos]

A billion no-hang runs locally. Lets progress here.

See also #1329

[ckormanyos]

OK the first draft of a non-hanging, yet clunky, version is in and cycling in CI.

Next steps involve:

• Add dedicated numerical checks at 32, 64, 128 bit. Testing on frexp is a bit light anyway and we could use some more.
• Optimize it, as there is ample room for improvement.

Cc: @mborland

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.8%. Comparing base (e72fd34) to head (5736a80).

Additional details and impacted files

@@            Coverage Diff            @@
##           develop   #1330     +/-   ##
=========================================
+ Coverage     98.8%   98.8%   +0.1%     
=========================================
  Files          278     279      +1     
  Lines        18034   18088     +54     
  Branches      1918    1926      +8     
=========================================
+ Hits         17812   17867     +55     
+ Misses         222     221      -1     

Files with missing lines	Coverage Δ
include/boost/decimal/detail/cmath/frexp.hpp	95.3% <100.0%> (+3.3%)	⬆️
test/github_issue_1329.cpp	100.0% <100.0%> (ø)

... and 3 files with indirect coverage changes

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e72fd34...5736a80. Read the comment docs.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[ckormanyos]

Hi Matt (@mborland), there are a few things woth discussing that are appearing in CI/CD.

On old GCC7 running on Drone, we hit the constexpr iteration limit of something like 262,144 when compiling erfc. This after the few trivial lines of code in frexp (albeit it might have a few new loop iterations now). I don't think the new frexp has huge amounts of new iterations. But I'm not sure if we should dive deeper or just increase the compiler limits on that run.

There is also verbose text regarding a note about some alignment running wild all over the place in CI/CD. It is ugly. I also get it locally. So we should really clean this up

Other than that, just the usual headache of CI...

[mborland]

If we can crank up the depth on GCC-7 that's fine with me. I don't think there's anything we can do about the alignment notifications since they're not warnings, just really annoying notifications about a change from like GCC 4.something

[ckormanyos]

If we can crank up the depth on GCC-7 that's fine with me.

Fine. I don't actually know where the compiler switches for Drone on that runner can be found.

Do you have any tip for that?

[mborland]

If we can crank up the depth on GCC-7 that's fine with me.

Fine. I don't actually know where the compiler switches for Drone on that runner can be found.

Do you have any tip for that?

Actually, I think the best move is to dump GCC-7 going into our first boost release. We already don't support GCC7 32-bit because it can't hang.

[ckormanyos]

If we can crank up the depth on GCC-7 that's fine with me.

Fine. I don't actually know where the compiler switches for Drone on that runner can be found.

Do you have any tip for that?

Actually, I think the best move is to dump GCC-7 going into our first boost release.

Yes please. Preferably immediately

[mborland]

If we can crank up the depth on GCC-7 that's fine with me.

Fine. I don't actually know where the compiler switches for Drone on that runner can be found.

Do you have any tip for that?

Actually, I think the best move is to dump GCC-7 going into our first boost release.

Yes please. Preferably immediately

Done, and updated the docs accordingly on this branch.

[ckormanyos]

Done, and updated the docs accordingly on this branch.

Thanks Matt.

Now something seemingly unrelated, kind of weird, is happenning on some of the runner environments in GHA? Or is that in Boost's CMake env?

[cppalliance-bot]

An automated preview of the documentation is available at https://1330.decimal.prtest3.cppalliance.org/libs/decimal/doc/html/index.html

If more commits are pushed to the pull request, the docs will rebuild at the same URL.

2026-02-05 13:40:47 UTC

[mborland]

Done, and updated the docs accordingly on this branch.

Thanks Matt.

Now something seemingly unrelated, kind of weird, is happenning on some of the runner environments in GHA? Or is that in Boost's CMake env?

It's an ubuntu problem. Happens from time to time.

[ckormanyos]

It's an ubuntu problem. Happens from time to time.

Got it. Thanks

[ckormanyos]

Note to self: One of the recent failed runners picks up Wdeprecated-declarations on std::denorm_absent in the numeric limits of cpp_dec_float. I believe it is clang 17 on __APPLE__, but I'm not entirely sure.

I'll disable the warning locally here, but this should be properly determined (which compiler picks it up) and dealt with in Multiprecision.

Cc: @mborland

[ckormanyos]

I think I need some help.

Matt (@mborland) do you see why the runner could still pick up Wdeprecated-declarations even after this disable clause?

How do we identify that compiler via preprocessor? From the build log, it looks like clang 17 on __APPLE__ Darwin.

[mborland]

I think I need some help.

Matt (@mborland) do you see why the runner could still pick up Wdeprecated-declarations even after this disable clause?

How do we identify that compiler via preprocessor? From the build log, it looks like clang 17 on __APPLE__ Darwin.

The macro __clang__ only defines to 1 or 0. To check versions you have to use __clang_major__

[ckormanyos]

How do we identify that compiler via preprocessor?

The macro __clang__ only defines to 1 or 0. To check versions you have to use __clang_major__

Oh cool this clears up a lot. I always thought it behaved like __GNUC__. Wow, I lived with that confusion for years. Thanks Matt.

Now this issue is sitting in $13$ places in Multiprecision in the numeric_limits everywhere from cpp_dec_float through tommath_int and every backend in between. We could either leave it or try to fix these in a mad dash.

I could repair them all myself prior to 1.91, but nobody is complaining about it. Your thoughts Matt?

[mborland]

For a small change we still have a few weeks. I think all the types already have warning wrappers around these deprecated members for MSVC

[ckormanyos]

For a small change we still have a few weeks. I think all the types already have warning wrappers around these deprecated members for MSVC

That is correct. I looked this morning. All $13$ places are wrapped. When we figure out the righ extension to the PP-#if-query, it's easy.

I'll find a minute to make an issue in MP.

[ckormanyos]

So I'm still going to do 1 more push on this branch to hit the 4 missing cover lines (2 each) in frexp and ldexp edge cases inf and NaN.

Then that should be about that for this one. But I'll still need another day maybe.