Fix issue with temporaries when compiling constexpr expression templates with clang

[marcoffee]

Fixed the issue discussed here. Currently, clang is unable to compile constexpr cpp_ints with expression templates enabled due to the tags being stored as reference inside the expressions. This PR adds a simple fix that prefer copying values to the expression when their type is an empty struct, which is the case for all functions used on expressions.

Error reproduction on compiler explorer: https://godbolt.org/z/fn69aGsWs

[mborland]

Sorry for the delay on this. Looks good to me! Once the CI cycles I'll get it merged

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 96.2%. Comparing base (9e39fe5) to head (1306fc4).

Additional details and impacted files

@@            Coverage Diff            @@
##           develop    #757     +/-   ##
=========================================
+ Coverage     96.2%   96.2%   +0.1%     
=========================================
  Files          300     301      +1     
  Lines        29466   29467      +1     
=========================================
+ Hits         28332   28333      +1     
  Misses        1134    1134             

Files with missing lines	Coverage Δ
...nclude/boost/multiprecision/detail/number_base.hpp	98.0% <ø> (ø)
test/constexpr_test_cpp_int_8.cpp	100.0% <100.0%> (ø)

---

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 9e39fe5...1306fc4. Read the comment docs.

🚀 New features to boost your workflow:

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

[ckormanyos]

I'm excited to try this on some curved domain-space geometrical calculations having dynamic allocation. Thanks for the initialtive and hard work @marcoffee, I know you put a lot of thought and dedication into this. Thanks @jzmaddock and @mborland for assisting on this effort, it was a large scope of changes, considering not only this, but the entire scope of issue(s).

[mborland]

@ckormanyos does the failure with cpp_double_float make any sense to you: https://github.com/boostorg/multiprecision/actions/runs/24259994693/job/71509762402?pr=757#step:10:5950

I don't see how this PR would affect that test at all? I ran develop and this PR on an ARM Mac with Clang-Darwin-22 instead of 17 and it was fine. I may just upgrade the version of macOS we are running on top of this PR to see what happens. 17 is pretty old at this point

[mborland]

Ok so we are already running macOS-latest so GHA must just be behind. The same test passed under the same compiler with C++17, and 20, just not 14. Perhaps this is a spurious failure?

[marcoffee]

I'm excited to try this on some curved domain-space geometrical calculations having dynamic allocation. Thanks for the initialtive and hard work @marcoffee, I know you put a lot of thought and dedication into this. Thanks @jzmaddock and @mborland for assisting on this effort, it was a large scope of changes, considering not only this, but the entire scope of issue(s).

I'm glad to be of help!

I don't see how this PR would affect that test at all?

I agree, it looks like this test is based on random-generated values without a fixed seed, which means they may fail/succeed depending on the value from stopwatch_type::now() at the first iteration. Maybe we should log its value or use a pre-defined value to ensure reproducibility.

[mborland]

Yeah, I like using fixed seed values exactly for this reason.

[ckormanyos]

The test test_cpp_double_float_bessel_versus_bin_and_decis one that I added recently. I like random seeds, but the test, silly enough, fails to print the input parameters that lead to the tolerance error. I guess this statistically just found an outlier completely unrelated to the scope of change in this PR.

I'll pin the seed on this one to $42$ or whatever ASAP, make sure it passes and freeze it. Or you can do that, since I'm about to nod off here.

But I'll note that theses limits need to be hammered. But I don't really have huge interest in this test because its primary use was as a sanity andperformance check. So a fixed seed is fine.

Cc: @marcoffee and @mborland

[ckormanyos]

See also #758. It was easy, so I just did it. Merge that thing into your branch. The seeds is/are fixed.

Sorry for this sporadic issue. I had not expected that one on a perf test.

Cc: @marcoffee and @mborland

[marcoffee]

See also #758. It was easy, so I just did it. Merge that thing into your branch. The seeds is/are fixed.

@ckormanyos thanks! I will merge it (to both PRs) as soon as it is merged to develop.

Sorry for this sporadic issue. I had not expected that one on a perf test.

No problem, thanks for the fix!

[jzmaddock]

Looks fine to me, I guess if we wanted to go the whole hog we could use compressed_pair inside class expression to reduce the size of expression objects further, but it's probably not a huge priority.

[ckormanyos]

Sorry for this sporadic issue. I had not expected that one on a perf test.

No problem, thanks for the fix!

Hi @marcoffee, the sporadic problem (statistically uncommon) has been eliminated via the use of fixed random seeding and predictable values in the performance heats.

Even though it's unlikely, you'd catch another outlier in a while, you should go ahead and merge develop into your branch.

Cc: @mborland and @jzmaddock

[mborland]

I have rebased this PR onto develop and kicked off the CI run

[marcoffee]

I have rebased this PR onto develop and kicked off the CI run

@mborland thanks!
This time it looks like the build timed out because some apt update steps took a long time to run.
Could you retry the build? @ckormanyos @jzmaddock

[mborland]

I think it's fine to merge

[mborland]

Thanks again for this! Please rebase your constexpr cpp_int on top of develop since you needed this fix