From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 49730 invoked by alias); 8 Aug 2019 03:24:51 -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 49721 invoked by uid 89); 8 Aug 2019 03:24:50 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=categories, H*i:sk:7c7366c, H*f:sk:7c7366c, apparent X-HELO: mailserver2.caci.com Received: from mailserver2.caci.com (HELO mailserver2.caci.com) (204.194.77.24) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 08 Aug 2019 03:24:48 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=caci.com; i=@caci.com; q=dns/txt; s=caci; t=1565234684; x=1596770684; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=0nU7zUVQONx7ndx6HXvaEJn4aUXMoSbGAUyo090Lz/E=; b=bfzop/KlGqRbo3mnkb4t1Mt9arOpy7UhzXV61+hVgZ6i7so9/RqfFgNV UPGHCPNjryo6UWpAlJUbMwe+9uqywWmxpnxvrBKMhfT01AjwpAnjYatxo 6aOAYnHJkua76e+2d2PHuFnSfMukbxP2QRvwjhs6uHYeUzqMw2ZvhAohI n0GkpnZLBEkuyNfCv92PESwMTLro16P+anb24q1+BCnPGsZZXrcAzBh7i WADc9YnFue53OmhEde3GKd+t8YUeAB4PP8OTS8QzNJ0c6vsfxxF37v22F pP61SaEdcm2ugVChUwoCznWLs1LOBYIOf5PR9GO3sIlPDmweMJIPsORp+ w==; Received: from cisexcasmb04-2a.caci.com ([10.201.50.158]) by mailserver2.caci.com with ESMTP/TLS/AES256-SHA; 07 Aug 2019 23:24:42 -0400 Received: from CISEXCASMB02-2A.caci.com (10.201.50.154) by CISEXCASMB04-2a.caci.com (10.201.50.158) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 7 Aug 2019 23:24:42 -0400 Received: from CISEXCASMB02-2A.caci.com ([fe80::f116:6d04:460e:9018]) by CISEXCASMB02-2a.caci.com ([fe80::f116:6d04:460e:9018%12]) with mapi id 15.00.1395.000; Wed, 7 Aug 2019 23:24:42 -0400 From: "Howland, Craig D. - US via newlib" Reply-To: "Howland, Craig D. - US" To: "newlib@sourceware.org" Subject: Re: [PATCH v3 2/3] Add default implementation of fenv.h and all methods Date: Thu, 08 Aug 2019 03:24:00 -0000 Message-ID: <1565234684974.8887@caci.com> References: <1565118798-16391-1-git-send-email-joel@rtems.org> <1565118798-16391-3-git-send-email-joel@rtems.org> <20190807083634.GA11632@calimero.vinschen.de> <1565184419338.12435@caci.com> ,<7c7366c4-17be-0b8e-3f79-4971e741253f@SystematicSw.ab.ca> In-Reply-To: <7c7366c4-17be-0b8e-3f79-4971e741253f@SystematicSw.ab.ca> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-SW-Source: 2019/txt/msg00431.txt.bz2 > From: newlib-owner@sourceware.org on behalf= of Brian Inglis > Sent: Wednesday, August 7, 2019 8:00 PM > To: newlib@sourceware.org > Subject: Re: [PATCH v3 2/3] Add default implementation of fenv.h and all = methods > > On 2019-08-07 07:28, Joel Sherrill wrote: > > On Wed, Aug 7, 2019 at 8:27 AM Howland, Craig D. via newlib wrote: > >> On Wednesday, August 7, 2019 4:36 AM Corinna Vinschen wrote: > >>> On Aug 6 14:13, Joel Sherrill wrote: > > Wouldn't it be clearer to conditionally define those constants based on s= ome > obviously fictional symbol e.g. > > #if FLOATING_POINT_EXCEPTIONS_SUPPORTED // replace by implementation symb= ol > /* > * The following macros are to be defined if the respective exception is > * supported by the implementation, each with a unique bit mask: > * > * FE_DIVBYZERO > * FE_INEXACT > * FE_INVALID > * FE_OVERFLOW > * FE_UNDERFLOW > * > * Other implementation-specific exceptions may be defined, and must start > * with FE_ followed by a capital letter. > * > * FE_ALL_EXCEPT must be defined as the logical OR of all exceptions. > */ > #define FE_DIVBYZERO 0x00000001 > #define FE_INEXACT 0x00000002 > #define FE_INVALID 0x00000004 > #define FE_OVERFLOW 0x00000008 > #define FE_UNDERFLOW 0x00000010 > > #define FE_ALL_EXCEPT \ > (FE_DIVBYZERO|FE_INEXACT|FE_INVALID|FE_OVERFLOW|FE_UNDERFLOW) > > /* > * The following macros are to be defined if the respective rounding dire= ction > * is supported by the implementation via the fegetround() and fesetround= () > * functions, each with a unique positive value. > * > * FE_DOWNWARD > * FE_TONEAREST > * FE_TOWARDZERO > * FE_UPWARD > * > * Other implementation-specific rounding modes may be defined, and must = start > * with FE_ followed by a capital letter. > */ > #define FE_DOWNWARD 1 > #define FE_TONEAREST 2 > #define FE_TOWARDZERO 3 > #define FE_UPWARD 4 > > #endif // FLOATING_POINT_EXCEPTIONS_SUPPORTED - replace by implementation= symbol > > #define FE_ALL_EXCEPT 0 /* NONE SUPPORTED IN PLACEHOLDER TEMPLATE */ > > >>>> +/* > >>>> + * The following typedefs are required. See the C and POSIX standar= ds > >> for > >>>> + * details: > >>>> + * > >>>> + * fenv_t > >>>> + * fexcept_t > >>>> + */ > >>>> +typedef size_t fenv_t; > >>>> +typedef size_t fexcept_t; > > >>> While these types are defined, the above macros are not. Wouldn't > >>> it make sense to define all or nothing by default? > > >> The standards require the types to be defined, but the individual macr= os > >> are to be defined only if supported by the implementation. The > >> default implementation being provided supports nothing, only > >> returning error, so it is proper for them to not be defined. But havi= ng > >> them there commented out to serve as a template seems to be a good thi= ng. > > > Quick reply. :) > > This is the POSIX language: > > "The ** header shall define the following constants if and only= if > > the implementation supports the floating-point exception by means of the > > floating-point functions *feclearexcept*(), *fegetexceptflag*(), > > *feraiseexcept*(), *fesetexceptflag*() and *fetestexcept*(). > > Each expands to an integer constant expression with values such that > > bitwise-inclusive ORs of all combinations of the constants result in > > distinct values." > > -- > Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada > Each of the 5 shown exceptions and each of the 4 showns rounding methods are individually optional, so implementations can define any or none of them. = So someone making an implementation has to go and decide for each one, anyway-= -an overall gate does not help there, and would be even one more thing that the implementer needed to add at no apparent gain. Notice also that for exceptions, the standard-required FE_ALL_EXCEPT is basically the same as FLOATING_POINT_EXCEPTIONS_SUPPORTED, except that it is created from the individual defines--the reverse of a an overall exceptions gate. (The standards are inconsistent in not providing a similar summary for the rounding modes, although with the individual defines it is less a requirement than a convenience. And it is easily understood why they did not, as the exception defines are required to be unique bits, while the rounding defines only distinct values--ORing doesn't allow individual identification of rounding mode defines.) Additionally, the individual definitions are intended to be the gate in user code, as they are only defined when supported. #include ... #if FE_ALL_EXCEPT feclearexcept(FE_ALL_EXCEPT); #if DEBUG puts("Floating point exceptions exist"); #endif #endif sin(arg); #if defined(FE_INVALID) if(fetestexcept(FE_INVALID) =3D=3D FE_INVALID) printf("sin(%g) raised in= valid exception", arg); #endif Notice also that there are two categories of things, so the single FLOATING_POINT_EXCEPTIONS_SUPPORTED in the question is only half of it. So even if there were to be an overall gate, there'd need to be two, one for exceptions and one for rounding directions. Craig