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 [170.10.133.124]) by sourceware.org (Postfix) with ESMTP id 5A8F0388C030 for ; Wed, 2 Jun 2021 18:44:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5A8F0388C030 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=1622659447; 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=hHJREpx7m2zfCIHhb68aN0XqRVvlZRAcb1wcIvDe0sM=; b=JJc+ewwM9PQGbqOW2v1WKEC52bCG/fEF/rkhzxPgD6bBPR+4oDxrU7vRuO0Za1UiZ1Y2c1 PWb/ERC5Py0JS3PuN+RejC0Vk0DWes1YPhN2gmlk1amWcZNjewXnrVQbDw70bgD8CDQC1p eL4M119t4a4IzoCFqeIepTJ5itfxBrc= Received: from mail-pg1-f199.google.com (mail-pg1-f199.google.com [209.85.215.199]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-158-Iywnl3aqNZegAWc62THuQg-1; Wed, 02 Jun 2021 14:44:04 -0400 X-MC-Unique: Iywnl3aqNZegAWc62THuQg-1 Received: by mail-pg1-f199.google.com with SMTP id 17-20020a630b110000b029022064e7cdcfso2311153pgl.10 for ; Wed, 02 Jun 2021 11:44:03 -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=hHJREpx7m2zfCIHhb68aN0XqRVvlZRAcb1wcIvDe0sM=; b=UL/hiGAlsdbzSXx6jF1jHX7EUr74dRe0JwGErG+35mR79MhE5HbI+K0inSN9vClNO3 UY6ByVRb2TVSPn1YLsSHRIcmm4OC5c4edtovgwxSKRTOBG1h8tfXZXFqc6uVovMc80V0 X75utfsZqgcSKaxa7lCxD+QU7J7yms3uIYQXV9qIWy0mTpSOV76Hk7SSKlb5gU8T2qCP yoR1Fo4kU6e4rnQ5j6TPr/BSCzddVlRl9BrEHlCfGSx80XJncl35Lcas0E9aWg+48jCk SNwOwh8s2LMs9NEsD7GBbNjFUrE4FsvoiXiN0k8Q4EpmCd+cRgTAdRXJGmIaaLBj6rlA 7qsQ== X-Gm-Message-State: AOAM531GBiMDXEAWm4H19HSvzqg6ezo9k1JJ0OXODv1U4Nmu1B5dnk7k M8cKlHlLw7x63HIaiK5zLXK7zScCtkJLYvBfWJEP51xLpdumCWru3JCiTFmj2CMMXyVrcAIZ+8R b5C/idPebj/WwPgkm+j4/Hm038o5bwmw= X-Received: by 2002:a17:90a:7305:: with SMTP id m5mr2700154pjk.83.1622659442762; Wed, 02 Jun 2021 11:44:02 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxTFllBNwJsOmCs9RY91jEMH4xlr28A40zIk5eS6lmO1fVjmwVBDQGwrLMtR1IuxLq1XReBRjcnsPHn5heBxYM= X-Received: by 2002:a17:90a:7305:: with SMTP id m5mr2700139pjk.83.1622659442557; Wed, 02 Jun 2021 11:44:02 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jeff Johnston Date: Wed, 2 Jun 2021 14:43:51 -0400 Message-ID: Subject: Re: incorrectly rounded square root To: joel@rtems.org Cc: Paul Zimmermann , 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.1 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: Wed, 02 Jun 2021 18:44:09 -0000 On Wed, Jun 2, 2021 at 9:08 AM Joel Sherrill wrote: > > > On Wed, Jun 2, 2021 at 2:51 AM Paul Zimmermann > wrote: > >> Hi Jeff, >> >> thank you for your answer. After investigating more it seems fesetround() >> is ineffective with newlib. Indeed if I print the result of fegetround() >> just after the fesetround() calls I get: >> >> fegetround: 0 >> RNDN: 0x1.ff83fp+63 >> fegetround: 0 >> RNDZ: 0x1.ff83fp+63 >> fegetround: 0 >> RNDU: 0x1.ff83fp+63 >> fegetround: 0 >> RNDD: 0x1.ff83fp+63 >> >> whereas with GNU libc I get: >> >> fegetround: 0 >> RNDN: 0x1.ff83fp+63 >> fegetround: 3072 >> RNDZ: 0x1.ff83eep+63 >> fegetround: 2048 >> RNDU: 0x1.ff83fp+63 >> fegetround: 1024 >> RNDD: 0x1.ff83eep+63 >> >> Thus it seems this has nothing to do with the square root. >> >> According to gdb the fesetround() code used is the following: >> >> (gdb) break fesetround >> Breakpoint 1 at 0x1650: file >> ../../../../../../newlib/libm/machine/x86_64/fenv.c, line 371. >> > > That is close to what I see in the source. That matches a variable > declaration in fesetround(). > > I was concerned that maybe the stub magic was resulting in empty > methods getting in for one of these. But doing an objdump on i386-rtems, > that doesn't appear to be the case. > > The implementation came from Cygwin and was lightly massaged to > get here. A student and I migrated that code to newlib in Feb 2020. > Corinna did some work in March 2021 to use this for Cygwin but I > don't see any reason it is broken. The i386-rtems installed sys/fenv.h > is the one for x86. > > fegetround() is quite simple and fesetround isn't much more than that. > > > https://sourceware.org/git/?p=newlib-cygwin.git;a=blob;f=newlib/libm/machine/shared_x86/fenv.c;h=ccc08e2d8103ab974baf8d9591f71e5565d73ace;hb=HEAD#l350 > > I really expected to see a build issue and you using a stub. Could you > confirm that the code we expect to be in those methods really is there > for you? The line number indicates you have the expected code but.... > > The rounding is set in the x87 control register and then if SSE is there > (dynamic check), it is also set in the SSE control register. The rounding > more is read from the x86 control register and the SSE control register is > ignored. > > Could you step through get and set and see if it looks like the x87 > control register is actually changed? > > I'm confused. This looks like it should work. > > --joel > > I'll second Joel's comment. The code is extremely close to the glibc code both in sqrtf and fesetround. The only thing I can think of is that the glibc code does the x87 stuff first and does the set back into FPU state before doing the SSE stuff. The newlib code sets back the FPU state at the end after the SSE stuff. Don't know if this is relevant or not. Any Cygwin users out there who can verify that the code is working/not working for them? -- Jeff J. >> Paul >> >> >>