[reach2sayan]

Fixes #66.

On ppc64le, GCC 9 to 14 reject the long double force_rounding asm added in #53 with "impossible constraint in 'asm'" when the value reaching it is a constant, for example interval<long double>(6) / interval<long double>(2) in a function compiled at -O1 or above. GCC cannot satisfy the in-out operand "+wa,d,m" with its several alternatives. Clang accepts it. #53 is on master, so this would ship in 1.93.

Change: in ppc_rounding_control.hpp, give the output and a matching input separately: "=wa,d,m"(r_) : "0,0,0"(r_). The alternatives and their order are unchanged, and the generated code for non-constant operands is identical (g++ -O2 -S, both long double ABIs).

Test: test_constant<T>() in test/rounding_mode.cpp (float, double, long double), which runs on the three ppc64le CI jobs.

• develop: rounding_mode.cpp does not compile with GCC at -O2
• this branch: all run tests pass at -O0, -O2 and -O3

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 82.79%. Comparing base (5d49468) to head (f8e8f7a).

Additional details and impacted files

@@           Coverage Diff            @@
##           develop      #69   +/-   ##
========================================
  Coverage    82.79%   82.79%           
========================================
  Files           23       23           
  Lines         1017     1017           
  Branches       412      412           
========================================
  Hits           842      842           
  Misses         167      167           
  Partials         8        8           

---

Continue to review full report in Codecov by Harness.

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

🚀 New features to boost your workflow:

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

[reach2sayan]

The icpx-2025 job is failing on develop and master too. It isn't caused by this PR. Every release link fails with add.o: file not recognized: file format not recognized, while debug passes. b2 - bfgroup/b2#616 switched the intel-linux release compile flags from -O3 -ip to -O3 -ipo, which emits LTO bitcode, but the link step didn't pass -ipo.

Should the CI be modified to include -ipo?

@Lastique This is what it could be

[Lastique]

If the change in b2 broke icpx with default linker flags then that looks like a regression in b2. Could you report it there? We can add the flag in CI config as a temporary workaround, but really it should be fixed in b2.

[Lastique]

I think, gcc has issues when the same argument is used as separate input and output parameters in the asm statement; it may mess up register allocation and produce incorrect asm sometimes. Although in this case there is no asm to generate, so the issue may not manifest.

Still, could you try adding an ",F" alternative to the original code?

[reach2sayan]

I think, gcc has issues when the same argument is used as separate input and output parameters in the asm statement; it may mess up register allocation and produce incorrect asm sometimes. Although in this case there is no asm to generate, so the issue may not manifest.

Still, could you try adding an ",F" alternative to the original code?

Tried. it just returns garbage value.
https://godbolt.org/z/1157TjYTG

[Lastique]

Tried. it just returns garbage value.

You're compiling for x86_64, which has different register constraints. Though I'm not familiar with PPC64 asm to tell whether the code works there.

There's also this alternative. Again, I can't easily tell from the asm whether it is working.

[reach2sayan]

Tried. it just returns garbage value.

You're compiling for x86_64, which has different register constraints. Though I'm not familiar with PPC64 asm to tell whether the code works there.

There's also this alternative. Again, I can't easily tell from the asm whether it is working.

I gave x86 because I can't read assembly so needed a printf proof and godbolt cant execute powerpc - but the point I wanted to make is just to say ,F doesnt work even on x86 () - I tested on QEMU locally

I'll quickly test the other alternative you suggested

@Lastique

[reach2sayan]

@Lastique I tried - and it works - but then it does have nested if else? Maybe we keep the current one - one size fit all?

[Lastique]

I think, I'd rather prefer the one with a single input-output parameter than separate input and output parameters. It also makes the clang workaround more obvious. There already is an #if __SIZEOF_LONG_DOUBLE__ == 8 condition there, so the added #elif defined(__clang__) won't make it worse. You can branch the entire asm statement, not just the constraint string. Just add a dedicated comment for the clang version as to why it's needed.

[Lastique]

Thanks.