On Fri, 27 Oct 2023, Jacek Caban wrote:
On 27/10/2023 16:51, LIU Hao wrote:
在 2023-10-26 19:15, Martin Storsjö 写道:
fabsf is available in UCRT on arm32/arm64, but not on x86.
nexttowardf is available in UCRT on all architectures, but this
functions takes two parameters, and the second parameter is a long
~~~~~~~~^
There is a typo in this message.
Other than that this series of patches look good to me.
It looks good to me as well, I'm glad to see those change.
After having this merged now, I ran into one case of breakage caused by
this; my nightly builds of llvm-mingw now has failures in compiler-rt's
tests:
https://github.com/mstorsjo/llvm-mingw/actions/runs/6680185681/job/18157214878
This seems to be a known issue in UCRT's scalbn function:
https://github.com/llvm/llvm-project/blob/llvmorg-17.0.3/compiler-rt/test/builtins/Unit/compiler_rt_scalbn_test.c#L64-L70
// Skip these tests for MSVC because its scalbn function always behaves as if
// the default rounding mode is set (FE_TONEAREST).
// Also skip for newlib because although its scalbn function does respect the
// rounding mode, where the tests trigger an underflow or overflow using a
// large exponent the result is rounded in the opposite direction to that which
// would be expected in the (FE_UPWARD) and (FE_DOWNWARD) modes.
# if !defined(_MSC_VER) && !defined(_NEWLIB_VERSION)
What do you think, should we revert this change for the scalbn/scalbnf
functions and go back to our internal implementation, or should I update
the compiler-rt tests to waive this known issue for defined(_WIN32)
instead of defined(_MSC_VER)?
Secondly, I was pointed to
https://github.com/msys2/MINGW-packages/pull/18978 which discusses various
other improvements and regressions in tests caused by this change - I
haven't had time to look closer at these yet.
// Martin
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
