On Wed, 5 Mar 2025, Jacek Caban wrote:
---
mingw-w64-crt/math/truncl.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/mingw-w64-crt/math/truncl.c b/mingw-w64-crt/math/truncl.c
index 3b47e53d1..d1b296661 100644
--- a/mingw-w64-crt/math/truncl.c
+++ b/mingw-w64-crt/math/truncl.c
@@ -3,7 +3,7 @@
* This file is part of the mingw-w64 runtime package.
* No warranty is given; refer to the file DISCLAIMER.PD within this package.
*/
-#include <fenv.h>
+
#include <math.h>
long double
@@ -16,8 +16,7 @@ truncl (long double _x)
unsigned short saved_cw;
unsigned short tmp_cw;
__asm__ __volatile__ ("fnstcw %0;" : "=m" (saved_cw)); /* save FPU control
word */
- tmp_cw = (saved_cw & ~(FE_TONEAREST | FE_DOWNWARD | FE_UPWARD |
FE_TOWARDZERO))
- | FE_TOWARDZERO;
+ tmp_cw = saved_cw | 0xc00; /* round towards zero */
I don't quite understand this change.
As far as I can see, the existing code does this, after expanding macros
and merging constants:
tmp_cw = (saved_cw & ~ 0x300) | 0x300;
And this is, practically speaking, the same as just tmp_cw = saved_cw |
0x300; - because FE_TOWARDZERO happens to be a value with all bits set.
Is this a typo, ir is it interconnected with the following patch? Is it a
bug in the preexisting code, as it looks like a functional change? It
would be good to have an explanation about why this is done here, even if
it may become apparent in the following commit.
// Martin
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
