From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id 9B2AA3853828 for ; Thu, 3 Jun 2021 15:50:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9B2AA3853828 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1622735439; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=i6x3WlXxS1Xc5YgSqZ1cOPSHJiSI1/nKb/Z0uKvvzGY=; b=XhokRvB+WrtAxrXjNoow1asuhMlDBoB9czvL1TaSx7a+mBgNcoAN5r7nCsJSyMmAOU/tcU rMNmp18CzYZQgnN8uxOSVlbr7Q9VDx1fgj663eE+zsh/XvJwKoAhVUnqr081mUPb36xkAi jv2PKU1ks7lE88w8vn7i1ZhZ5AeTzLY= Received: from mail-pg1-f200.google.com (mail-pg1-f200.google.com [209.85.215.200]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-509-2TtyX1IGN_ihT7DAmM2F3w-1; Thu, 03 Jun 2021 11:50:36 -0400 X-MC-Unique: 2TtyX1IGN_ihT7DAmM2F3w-1 Received: by mail-pg1-f200.google.com with SMTP id v12-20020a63d54c0000b02902167d3d2f08so4189844pgi.13 for ; Thu, 03 Jun 2021 08:50:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=i6x3WlXxS1Xc5YgSqZ1cOPSHJiSI1/nKb/Z0uKvvzGY=; b=rYctVKFWSfWZLykOu4HwmLg4UrcSGD3JotM6fMf6FutEHv1CipJSb9tn+ez+qZxR0U 7crSZxfgxqEOuSEmV+BX8n8ICT2HH8m6h/9MzHzK7j/8ZVU7czff3noIY+meoLjJ7xVk y/GsGz80pNEYQVVjIzA8pK/hrVBlDkE5l8FrpJzkEArbnzJKYhdcuwpxu3W9L2Vcvp06 Wlb9lFOpEWwgcyRPqQ4NuLVx8JpvtQLZ91DSwH2NrtuGbAL/CYrMqwZB5YJVCMXRS9Rc zOB+CCp/MQ8A+8GF8BiKuMj0ph1Z6ny0YmaiCZId7jVqpKIbfPXRIA7iLk7o3lTXNm5M GgOQ== X-Gm-Message-State: AOAM533wNczbDrZ7uMb1ub0St9sL0QI2wRcvnJJvLnC/lbUdGpBvECD0 0sCbT9G8YWJoigeC/H0Frf9DKgyysgz9w6OZliXtWC4hFkWlduBTFs5S4eI0jQPrGex7eWQggUW Y7/27WVDIQjHuAG3XHV9GA9/QZLrhKY4= X-Received: by 2002:a17:90a:3948:: with SMTP id n8mr658904pjf.32.1622735435384; Thu, 03 Jun 2021 08:50:35 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwZ22gmDVJMbS4rfsnT/pX7yOMsoxRjmy+z3Knw4BmfRihfTpJ5DFN2Xmewk8UuKVg0RKcMnnyzfAA1RGs6h58= X-Received: by 2002:a17:90a:3948:: with SMTP id n8mr658882pjf.32.1622735435115; Thu, 03 Jun 2021 08:50:35 -0700 (PDT) MIME-Version: 1.0 References: <2f8796f4-f164-5734-16ca-9a392e788beb@gmail.com> In-Reply-To: From: Jeff Johnston Date: Thu, 3 Jun 2021 11:50:24 -0400 Message-ID: Subject: Re: incorrectly rounded square root To: Paul Zimmermann Cc: joel@rtems.org, Newlib Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=jjohnstn@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, HTML_MESSAGE, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, 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 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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: Thu, 03 Jun 2021 15:50:50 -0000 Hi Paul, 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? 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. -- Jeff J. On Thu, Jun 3, 2021 at 6:22 AM Paul Zimmermann wrote: > Hi Jeff, > > I've investigated and found (partially) the cause of the problem. When I > compile my program, gcc uses the system fenv.h, which contains > FE_TONEAREST=0, > FE_DOWNWARD=0x400, FE_UPWARD=0x800, and FE_TOWARDZERO=0xc00 in > /usr/include/bits/fenv.h. > > However, the values in x86_64/newlib/targ-include/sys/fenv.h are different: > FE_TONEAREST=0, FE_DOWNWARD=1, FE_UPWARD=2, FE_TOWARDZERO=3. Thus the test > at the beginning of fesetround in newlib/libm/machine/x86_64/fenv.c fails > except for round=FE_TONEAREST: > > /* Will succeed for any valid value of the input parameter. */ > if (round < FE_TONEAREST || round > FE_TOWARDZERO) > return EINVAL; > > enter fesetround, round=0 use_sse=1 > enter fesetround, round=3072 use_sse=1 > enter fesetround, round=2048 use_sse=1 > enter fesetround, round=1024 use_sse=1 > > This explains why the other modes are not set. > > A first question is why Newlib and the system libm (here glibc) use > different > constants for the rounding modes. > > Now if I compile with -I/tmp/x86_64/include (where the Newlib fenv.h is > installed) I get: > > enter fesetround, round=0 use_sse=1 > enter fesetround, round=3 use_sse=1 > enter fesetround, round=2 use_sse=1 > enter fesetround, round=1 use_sse=1 > > but I still do get the same results whatever the rounding mode! > > If I look at the cw and mxcsr registers like in Newlib fenv.c, I get with > glibc > (after the fesetround call): > > fegetround: 0 > cw=895 mxcsr=8064 > RNDN: 0x1.ff83fp+63 > fegetround: 3072 > cw=3967 mxcsr=32672 > RNDZ: 0x1.ff83eep+63 > fegetround: 2048 > cw=2943 mxcsr=24480 > RNDU: 0x1.ff83fp+63 > fegetround: 1024 > cw=1919 mxcsr=16288 > RNDD: 0x1.ff83eep+63 > > and with Newlib: > > fegetround: 0 > cw=895 mxcsr=8064 > RNDN: 0x1.ff83fp+63 > fegetround: 3 > cw=3967 mxcsr=32640 > RNDZ: 0x1.ff83fp+63 > fegetround: 2 > cw=2943 mxcsr=24448 > RNDU: 0x1.ff83fp+63 > fegetround: 1 > cw=1919 mxcsr=16256 > RNDD: 0x1.ff83fp+63 > > The cw values do match but not the mxcsr values. > > Best regards, > Paul > > > Something weird is going on. I condensed the newlib code into the > > following files and when I compile and run the test, > > it works as expected: > > > > gcc -std=c99 -g3 -O0 test_sqrt.c fesetround.c ef_sqrt.c > > [jjohnstn@localhost shared_x86]$ ./a.out > > RNDN: 0x1.ff83fp+63 > > RNDZ: 0x1.ff83eep+63 > > RNDU: 0x1.ff83fp+63 > > RNDD: 0x1.ff83eep+63 > > > > Can you verify that you are calling the fesetround in fenv.c and what > > configuration call did you use for building newlib? > >