Update fptraits.hpp for gcc/windows/aarch64. #1350

jzmaddock · 2026-01-13T12:09:37Z

Also adds better error checking.
Fixes #1348

Also adds better error checking. Fixes #1348

mborland · 2026-01-13T13:19:38Z

include/boost/math/special_functions/detail/fp_traits.hpp

 // PowerPC extended double precision format (128 bits)

+static_assert(LDBL_MANT_DIG == 113, "Oops, assumption that long double is a 128-bit quantity is incorrect!!");
+


In the PowerPC case should we check both 106 and 113 for LDBL_MANT_DIG? I assume the original code is old enough that 106 was the only option at the time.

Not in the same branch, everything has to go to the correct #if branch otherwise we don't get the correct bits.

jzmaddock · 2026-01-16T12:48:52Z

@mborland I can't seem to get CUDA/SYCL correct: am I correct in thinking that long double is 64 bit on the device and 80-bit on the host? If so is there a good way to configure that?

mborland · 2026-01-16T12:58:26Z

@mborland I can't seem to get CUDA/SYCL correct: am I correct in thinking that long double is 64 bit on the device and 80-bit on the host?

That is correct.

If so is there a good way to configure that?

I think we'd need to have one set of functions marked host and one set marked device and then let the compiler pick the right one. I'm out of town for the long weekend (MLK day), but I can add those on Tuesday if you'd like.

jzmaddock · 2026-01-18T19:48:25Z

I think we'd need to have one set of functions marked host and one set marked device and then let the compiler pick the right one. I'm out of town for the long weekend (MLK day), but I can add those on Tuesday if you'd like.

Hmm, I suspect that since the functions aren't dependent on any template parameter, the static_assert will be triggered irrespective of whether the function is called or not.

mborland · 2026-01-20T16:40:18Z

I think we'd need to have one set of functions marked host and one set marked device and then let the compiler pick the right one. I'm out of town for the long weekend (MLK day), but I can add those on Tuesday if you'd like.

Hmm, I suspect that since the functions aren't dependent on any template parameter, the static_assert will be triggered irrespective of whether the function is called or not.

I guess I was thinking about moving the static_assert into the getter and setter functions like:

__host__ get_bits() { static_assert(LDBL_MANT_DIG == 64); 80 bit impl; }
__device__ get_bits() { static_assert(LDBL_MANT_DIG == 53); 64 bit impl; } 

__host__ set_bits() { static_assert(LDBL_MANT_DIG == 64); 80 bit impl; }
__device__ set_bits() { static_assert(LDBL_MANT_DIG == 53); 64 bit impl; }

The rub is then the tag is wrong on device?

mborland · 2026-01-20T17:46:47Z

Actually, even easier is removing the check for GPU platforms. I was wrong and long double is entirely unsupported and warns if used.. There are also no GPU markers on any of the long double functions so they will error if called anyway.

codecov · 2026-01-20T19:32:21Z

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 95.29%. Comparing base (1d670c8) to head (935e699).
⚠️ Report is 7 commits behind head on develop.

Additional details and impacted files

@@           Coverage Diff            @@
##           develop    #1350   +/-   ##
========================================
  Coverage    95.29%   95.29%           
========================================
  Files          814      814           
  Lines        67422    67422           
========================================
  Hits         64249    64249           
  Misses        3173     3173

Files with missing lines	Coverage Δ
.../boost/math/special_functions/detail/fp_traits.hpp	`100.00% <ø> (ø)`

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 1d670c8...935e699. Read the comment docs.

🚀 New features to boost your workflow:

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

jzmaddock · 2026-01-24T12:53:16Z

Looks like this one is good to go @mborland ?

mborland · 2026-01-24T14:04:12Z

Looks like this one is good to go @mborland ?

Yes. In it goes.

ckormanyos · 2026-01-24T19:01:50Z

Oh geez, literally 5 minutes after this merge, my builds on arm-none-eabi for 32-bit microcontrollers broke.

In file included from ../../boost-root/boost/math/special_functions/fpclassify.hpp:21,
                 from ../../boost-root/boost/math/special_functions/cbrt.hpp:23,
                 from ./src/app/benchmark/app_benchmark_boost_math_cbrt_tgamma.cpp:40:
../../boost-root/boost/math/special_functions/detail/fp_traits.hpp:441:29: error: static assertion failed: Oops, assumption that long double is a 128-bit quantity is incorrect!!
  441 | static_assert(LDBL_MANT_DIG == 113, "Oops, assumption that long double is a 128-bit quantity is incorrect!!");
      |                             ^
../../boost-root/boost/math/special_functions/detail/fp_traits.hpp:441:29: note: the comparison reduces to '(53 == 113)'
In file included from ../../boost-root/boost/math/special_functions/sign.hpp:21,
                 from ../../boost-root/boost/math/tools/roots.hpp:20,
                 from ../../boost-root/boost/math/special_functions/bessel.hpp:22,
                 from ./src/app/benchmark/app_benchmark_boost_math_cyl_bessel_j.cpp:71:
../../boost-root/boost/math/special_functions/detail/fp_traits.hpp:441:29: error: static assertion failed: Oops, assumption that long double is a 128-bit quantity is incorrect!!
  441 | static_assert(LDBL_MANT_DIG == 113, "Oops, assumption that long double is a 128-bit quantity is incorrect!!");
      |                             ^
../../boost-root/boost/math/special_functions/detail/fp_traits.hpp:441:29: note: the comparison reduces to '(53 == 113)'
In file included from ../../boost-root/boost/math/special_functions/fpclassify.hpp:21,
                 from ../../boost-root/boost/math/special_functions/cbrt.hpp:23,
                 from ./src/app/benchmark/app_benchmark_boost_multiprecision_cbrt.cpp:43:
../../boost-root/boost/math/special_functions/detail/fp_traits.hpp:441:29: error: static assertion failed: Oops, assumption that long double is a 128-bit quantity is incorrect!!
  441 | static_assert(LDBL_MANT_DIG == 113, "Oops, assumption that long double is a 128-bit quantity is incorrect!!");
      |                             ^
../../boost-root/boost/math/special_functions/detail/fp_traits.hpp:441:29: note: the comparison reduces to '(53 == 113)'

ckormanyos · 2026-01-24T19:06:23Z

I could add some lines around line 273 to pick up arm-none-eabi-GCC. But, noting that this toolchain is not one of the ones officially supported in Boost.Math, I could also leave it. but it would be a shame if I couldn't compile math any more on ARM aarch32. I need to check if there is a good fix for this one

ckormanyos · 2026-01-24T19:14:43Z

Around lines 273, I could add

(defined(__arm__) || defined(__thumb__))

which will NOT pick up __aarch64__. THen at least I get my Cortex(R) controllers?

jzmaddock · 2026-01-25T17:55:51Z

Thanks for this @ckormanyos , just thinking out loud here, I wonder if it's possible to change the default branch to only check long double sizes if that function is actually used (we would need to make it a template somehow)? Otherwise we risk this issue coming up again and again as new platforms get used.

ckormanyos · 2026-01-25T21:32:06Z

I wonder if it's possible to change the default branch to only check long double sizes if that function is actually used (we would need to make it a template somehow)? Otherwise we risk this issue coming up again and again as new platforms get used.

You know @jzmaddock, I still struggled with this one. I got it working locally, but still had to disable some tests in my embedded CI/CD.

So I haven't fully understood the testing logic yet. At this moment, I think we have something that passes CI/CD on Boost.Math. And I can work successfully locally with it.

But indeed, I think the logic could and probably will be refined. I just got in a super-hurry yesterday and put in the minimal PP-stuff I needed for my local builds. It can surely be improved down the road.

mborland · 2026-01-26T13:52:31Z

I'm wondering if we can't remove much of the use? For instance fpclassify, isnan etc. were standardized in C++11. These fp_traits seem to be the predecessor to that, which can now be safely removed since we require C++14.

jzmaddock · 2026-01-26T15:56:00Z

I'm wondering if we can't remove much of the use? For instance fpclassify, isnan etc. were standardized in C++11. These fp_traits seem to be the predecessor to that, which can now be safely removed since we require C++14.

Perhaps, but in general they're pretty efficient and portable. They also correctly detect NaN's in situations where some std::isnan implementations fail to do so.

mborland · 2026-01-26T16:35:00Z

This broke the PPC64LE QEMU runners from Boost.CI:

In file included from ./boost/math/special_functions/fpclassify.hpp:21,
                 from ./boost/math/special_functions/next.hpp:20,
                 from libs/decimal/test/test_legendre.cpp:31:
./boost/math/special_functions/detail/fp_traits.hpp:367:29: error: static assertion failed: Oops, assumption that long double is a 128-bit quantity is incorrect!!
  367 | static_assert(LDBL_MANT_DIG == 113, "Oops, assumption that long double is a 128-bit quantity is incorrect!!");
      |                             ^
./boost/math/special_functions/detail/fp_traits.hpp:367:29: note: the comparison reduces to '(53 == 113)'

    "g++"   -std=c++14 -fvisibility-inlines-hidden -m64 -pthread -O3 -finline-functions -Wno-inline -Wall -Werror -fvisibility=hidden -Wall -Wconversion -Wextra -Wfloat-equal -Wold-style-cast -Wshadow -Wsign-conversion -Wundef -Wuseless-cast -DBOOST_ALL_NO_LIB=1 -DBOOST_DECIMAL_QEMU_TEST -DNDEBUG   -I"." -I"/boost/libs/decimal/include"  -c -o "bin.v2/libs/decimal/test/test_legendre.test/gcc-14/release/power_64/cxxstd-14-iso/link-static/threading-multi/visibility-hidden/test_legendre.o" "libs/decimal/test/test_legendre.cpp"

ckormanyos · 2026-01-26T16:59:15Z

This broke the PPC64LE QEMU runners from Boost.CI

Hi @mborland, good catch.

Ugghhh what exactly broke the 64-bit Power PC QEMU runners?

Were my very recent changes for __arm__ the culprit, or do you mean this entire PR?

mborland · 2026-01-26T17:04:13Z

The entire PR, since you didn't touch this path. I'm thinking it may be time to roll this back. There's going to be lots of other platforms we don't account for I'm sure. I'll defer to @jzmaddock

ckormanyos · 2026-01-26T17:23:55Z

I'm thinking it may be time to roll this back. There's going to be lots of other platforms we don't account for I'm sure. I'll defer, ...

That is a good consideration Matt (@mborland). It's one of those things, ... do you roll back or press on?

I have Boost.Math running on embedded __arm__, __riscv__, and a few others in addition to the classic host workstations like PCs and LINUX.

For the record, I can live with this PR.

So if we get the failed runners on PPC-64 working, that would be sufficient for me at the moment.

Cc: @jzmaddock

jzmaddock · 2026-01-27T12:28:04Z

This broke the PPC64LE QEMU runners from Boost.CI:

Where can I see these running?

I'm interested in the output from math_info.cpp on these platforms if possible?

Meanwhile, see if #1354 helps.

mborland · 2026-01-27T13:54:54Z

This broke the PPC64LE QEMU runners from Boost.CI:

Where can I see these running?

Here is an example: https://github.com/cppalliance/decimal/actions/runs/21370721961/job/61514255669

I'm interested in the output from math_info.cpp on these platforms if possible?

I'll have to see if I can get these containers running locally to give it a shot. It's pulling in math from develop in the CI.

Meanwhile, see if #1354 helps.

Update fptraits.hpp for gcc/windows/aarch64.

b390d09

Also adds better error checking. Fixes #1348

mborland reviewed Jan 13, 2026

View reviewed changes

fptraits.hpp: Update tests for arm64 and CUDA.

0c9bbf6

Remove GPU specific check

37daf3e

Only check SYCL long doubles

935e699

mborland force-pushed the issue1348 branch from b150b10 to 935e699 Compare January 20, 2026 18:10

mborland merged commit 627174f into develop Jan 24, 2026
65 checks passed

mborland deleted the issue1348 branch January 24, 2026 14:04

		// PowerPC extended double precision format (128 bits)

		static_assert(LDBL_MANT_DIG == 113, "Oops, assumption that long double is a 128-bit quantity is incorrect!!");

Update fptraits.hpp for gcc/windows/aarch64. #1350

Update fptraits.hpp for gcc/windows/aarch64. #1350

Uh oh!

Conversation

jzmaddock commented Jan 13, 2026

Uh oh!

mborland Jan 13, 2026

Choose a reason for hiding this comment

Uh oh!

jzmaddock Jan 16, 2026

Choose a reason for hiding this comment

Uh oh!

jzmaddock commented Jan 16, 2026

Uh oh!

mborland commented Jan 16, 2026

Uh oh!

jzmaddock commented Jan 18, 2026

Uh oh!

mborland commented Jan 20, 2026

Uh oh!

mborland commented Jan 20, 2026

Uh oh!

codecov bot commented Jan 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

jzmaddock commented Jan 24, 2026

Uh oh!

mborland commented Jan 24, 2026

Uh oh!

Uh oh!

ckormanyos commented Jan 24, 2026

Uh oh!

ckormanyos commented Jan 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ckormanyos commented Jan 24, 2026

Uh oh!

jzmaddock commented Jan 25, 2026

Uh oh!

ckormanyos commented Jan 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mborland commented Jan 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jzmaddock commented Jan 26, 2026

Uh oh!

mborland commented Jan 26, 2026

Uh oh!

ckormanyos commented Jan 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mborland commented Jan 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ckormanyos commented Jan 26, 2026

Uh oh!

jzmaddock commented Jan 27, 2026

Uh oh!

mborland commented Jan 27, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

codecov bot commented Jan 20, 2026 •

edited

Loading

ckormanyos commented Jan 24, 2026 •

edited

Loading

ckormanyos commented Jan 25, 2026 •

edited

Loading

mborland commented Jan 26, 2026 •

edited

Loading

ckormanyos commented Jan 26, 2026 •

edited

Loading

mborland commented Jan 26, 2026 •

edited

Loading