From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14161 invoked by alias); 27 Aug 2019 17:11:03 -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 14153 invoked by uid 89); 27 Aug 2019 17:11:02 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy= X-HELO: esa3.mentor.iphmx.com Received: from esa3.mentor.iphmx.com (HELO esa3.mentor.iphmx.com) (68.232.137.180) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 27 Aug 2019 17:11:02 +0000 IronPort-SDR: CthESipWfHURywWu1B0A6ErMgQsKJfMF3lOnf/Wf7WxsOtrl3sdlX0q9h/zCG+s+xfwG29wwZy ms8chfzP/JvGQWBaJTSGBfyOZQtrxbf/ug0vtymwcKqNIwJRwrBd0+4o3BGMZ0Ht+ZPEWcIzhW /A3d5nx+8ZaEZX3LGLpsr+2DMFc/WzkBhZ7zqtI5eTn6Zye//cMHMBM0fPBKR7X5TdID6X6R8K Ti+C7T7EJqVkMWlwpJGd+hFXbtihCGN9KKm0q9FMoU5G9JGyddySRE2QlYO5TRdw6ZonfK9RJB 6xA= Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa3.mentor.iphmx.com with ESMTP; 27 Aug 2019 09:11:00 -0800 IronPort-SDR: KRurLBvjLzocV6qhMWCSRtgrMEuZ6J1A75ks/C+UnsB8JIsvPQ/jodJXKvi7C2Y2td2vvb8X6j hm+maNp/nAoNVoiTjyLiQmuWD7R4T1JZCDM97uJ3cVwfdd4jwP7nUAMFjer/Cz6ahr4dDPw5Nh UwnkUwe+69lUfuGDlbfdEC+hrgNgkSk3aNW0HwMwqL/KFwv9FkKOA8Ef5sgM85hmOdg98fqyEw HA64zus90GXndWa3UD9rRY2jzTrrU0dCbcsCgldAFTsx6WOU6FjJDZZ6WoXQ8hyufHrzzS/u9I tGU= Date: Tue, 27 Aug 2019 17:11:00 -0000 From: Joseph Myers To: Joel Sherrill CC: Newlib Subject: Re: i386 and x86_64 fenv support In-Reply-To: Message-ID: References: User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Return-Path: joseph@codesourcery.com X-SW-Source: 2019/txt/msg00517.txt.bz2 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). -- Joseph S. Myers joseph@codesourcery.com