From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 71100 invoked by alias); 27 Aug 2019 17:30:43 -0000 Mailing-List: contact newlib-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: newlib-owner@sourceware.org Received: (qmail 71090 invoked by uid 89); 27 Aug 2019 17:30:42 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-4.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=soft, HX-Gm-Message-State:APjAAAU X-HELO: mail-oi1-f181.google.com Received: from mail-oi1-f181.google.com (HELO mail-oi1-f181.google.com) (209.85.167.181) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 27 Aug 2019 17:30:41 +0000 Received: by mail-oi1-f181.google.com with SMTP id 16so15583971oiq.6 for ; Tue, 27 Aug 2019 10:30:41 -0700 (PDT) Return-Path: Received: from mail-ot1-f54.google.com (mail-ot1-f54.google.com. [209.85.210.54]) by smtp.gmail.com with ESMTPSA id m10sm5546231otq.0.2019.08.27.10.30.39 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Aug 2019 10:30:39 -0700 (PDT) Received: by mail-ot1-f54.google.com with SMTP id o101so19426451ota.8 for ; Tue, 27 Aug 2019 10:30:39 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Reply-To: joel@rtems.org From: Joel Sherrill Date: Tue, 27 Aug 2019 17:30:00 -0000 Message-ID: Subject: Re: i386 and x86_64 fenv support To: Joseph Myers Cc: Newlib Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2019/txt/msg00518.txt.bz2 On Tue, Aug 27, 2019 at 12:11 PM Joseph Myers wrote: > > On Tue, 27 Aug 2019, Joel Sherrill wrote: > > > FWIW this moved up in importance because the x86_64 RTEMS toolchain > > won't build with the gcc/newlib master because libquadmath assumes the > > existence of the FE_TONEAREST since it the autoconf probe now sees > > we have fenv.h support now. This is probably a bug in this code since it > > can't assume a rounding mode is supported. > > The rule in glibc is that architectures without support for rounding modes > still define FE_TONEAREST, and return it from fegetround and accept it for > fesetround, reflecting that to-nearest is the default (and only) rounding > mode. > > That is, only architectures that don't support to-nearest at all should > fail to define FE_TONEAREST (and libquadmath doesn't support any such > architectures anyway). So the stub version should define FE_TONEAREST, return 0 if that's the input to fesetround, and return FE_TONEAREST from fegetround? The discussion when the behavior was picked was to match soft float. But we could have easily missed something. There are other FE_xxx constants used in libquadmath/math and I haven't looked at them in detail but grep output looked like they were all wrapped in ifdef's. --joel > > -- > Joseph S. Myers > joseph@codesourcery.com