From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sourceware.org (Postfix) with ESMTPS id 2B03E3857033 for ; Fri, 4 Jun 2021 07:14:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2B03E3857033 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=inria.fr Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=inria.fr IronPort-HdrOrdr: =?us-ascii?q?A9a23=3Ayxf8b67Kp8+RqBrPwgPXwNTXdLJyesId70hD?= =?us-ascii?q?6qkRc202TiX2ra+TdZgguyMc6wxhO03I++rgBEDoexq1nqKdirN9AV7NZmPbUR?= =?us-ascii?q?OTTL2LO+PZrwHdJw=3D=3D?= X-IronPort-AV: E=Sophos;i="5.83,247,1616454000"; d="scan'208";a="383417646" Received: from tomate.loria.fr (HELO tomate) ([152.81.10.51]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Jun 2021 09:14:07 +0200 Date: Fri, 04 Jun 2021 09:14:07 +0200 Message-Id: From: Paul Zimmermann To: Jeff Johnston Cc: joel@rtems.org, newlib@sourceware.org In-Reply-To: (message from Jeff Johnston on Thu, 3 Jun 2021 11:50:24 -0400) Subject: Re: incorrectly rounded square root References: <2f8796f4-f164-5734-16ca-9a392e788beb@gmail.com> X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: newlib@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Newlib mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2021 07:14:11 -0000 Hi Jeff, > I figured the values were off when I had to hard-code them in my own > test_sqrt.c but forgot to include that info in my note. > > Now, that said, using the code I attached earlier, I am seeing the exact > values you are quoting above for glibc for the mxcsr register and the round > is working. Have your > tried running that code? yes it works as expected, but it doesn't work with Newlib's fenv.h and libm.a (see below). > The mxcsr values you are seeing that are different are not due to the > fesetround code. The code is shifting the round value 13 bits > and for 3, that ends up being 0x6000. It is masking mxcsr with 0xffff9fff > first so when you start with 0x1fxx and end up with 0x7fxx, the code is > doing what is supposed to do. > The difference in values above is 0x20 (e.g. 0x7fa0 vs 0x7f80) which is a > bit in the last 2 hex digits which isn't touched by the code logic. here is how to reproduce the issue: tar xf newlib-4.1.0.tar.gz cd newlib-4.1.0 mkdir build cd build ../configure --prefix=/tmp --disable-multilib --target=x86_64 make -j4 make install $ cat test_sqrt_2.c #include #include #include #ifdef NEWLIB /* RedHat's libm claims: undefined reference to `__errno' in j1f/y1f */ int errno; int* __errno () { return &errno; } #endif int main() { int rnd[4] = { FE_TONEAREST, FE_TOWARDZERO, FE_UPWARD, FE_DOWNWARD }; char Rnd[4] = "NZUD"; float x = 0x1.ff07fep+127f; float y; for (int i = 0; i < 4; i++) { unsigned short cw; unsigned int mxcsr = 0; fesetround (rnd[i]); __asm__ volatile ("fnstcw %0" : "=m" (cw) : ); __asm__ volatile ("stmxcsr %0" : "=m" (mxcsr) : ); y = sqrtf (x); printf ("RND%c: %a cw=%u mxcsr=%u\n", Rnd[i], y, cw, mxcsr); } } With GNU libc: $ gcc -fno-builtin test_sqrt_2.c -lm $ ./a.out RNDN: 0x1.ff83fp+63 cw=895 mxcsr=8064 RNDZ: 0x1.ff83eep+63 cw=3967 mxcsr=32672 RNDU: 0x1.ff83fp+63 cw=2943 mxcsr=24480 RNDD: 0x1.ff83eep+63 cw=1919 mxcsr=16288 With Newlib: $ gcc -I/tmp/x86_64/include -DNEWLIB -fno-builtin test_sqrt_2.c /tmp/libm.a $ ./a.out RNDN: 0x1.ff83fp+63 cw=895 mxcsr=8064 RNDZ: 0x1.ff83fp+63 cw=3967 mxcsr=32640 RNDU: 0x1.ff83fp+63 cw=2943 mxcsr=24448 RNDD: 0x1.ff83fp+63 cw=1919 mxcsr=16256 Can you reproduce that on x86_64 Linux? Paul