From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id 4C4993858D3C for ; Fri, 8 Apr 2022 10:09:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4C4993858D3C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=foss.arm.com Authentication-Results: sourceware.org; spf=none smtp.mailfrom=foss.arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id DC8E111FB; Fri, 8 Apr 2022 03:09:44 -0700 (PDT) Received: from [10.57.40.209] (unknown [10.57.40.209]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 414023F73B; Fri, 8 Apr 2022 03:09:44 -0700 (PDT) Message-ID: <7d0a81fb-4553-a895-1353-97a6af61e6e3@foss.arm.com> Date: Fri, 8 Apr 2022 11:09:42 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: [PATCH V2] Aarch32/64: Support __FLT_EVAL_METHOD__ values other than 0, 1, 2 Content-Language: en-GB To: Andrea Corallo , Torbjorn SVENSSON Cc: "newlib@sourceware.org" References: From: Richard Earnshaw In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3498.1 required=5.0 tests=BAYES_00, GIT_PATCH_0, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, KAM_NUMSUBJECT, NICE_REPLY_A, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org 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: Fri, 08 Apr 2022 10:09:47 -0000 On 04/04/2022 15:53, Andrea Corallo wrote: > Torbjorn SVENSSON writes: > >> Hello, >> >> It would have been easier to review the patch if it was inline, but >> this will have to do anyway. > > Hi Torbjorn, > > sorry most mail readers easily show inline attacchaments of type > "text/plain" allowing for inline reply, at the same time this way they > can still retain the notion of attached file. This is how I rutinary > sent my patches to other GNU projects (including GCC) so far. Has > newlib some specific rule around this? > >> I think there is a typo in math.h. Aren't you supposed to do "#ifndef" and not "#ifdef"? > > I guess we are talking about this hunk? > > #ifdef __epiphany__ > diff --git a/newlib/libc/include/math.h b/newlib/libc/include/math.h > index ba1a8a17e..da056b5b6 100644 > --- a/newlib/libc/include/math.h > +++ b/newlib/libc/include/math.h > @@ -158,6 +158,15 @@ extern int isnan (double); > #else > /* Implementation-defined. Assume float_t and double_t have been > * defined previously for this configuration (e.g. config.h). */ > + > + /* If __DOUBLE_TYPE is defined (__FLOAT_TYPE is then supposed to be > + defined as well) float_t and double_t definition is suggested by > + an arch specific header. */ > + #ifdef __DOUBLE_TYPE > + typedef __DOUBLE_TYPE double_t; > + typedef __FLOAT_TYPE float_t; > + #endif > + /* Assume config.h has provided these types. */ > #endif > #else > /* Assume basic definitions. */ > > I believe the #ifdef is correct. As the comment suggests if > __DOUBLE_TYPE is defined we'll use it to define double_t otherwise we > assume is config.h has provided the type definition. > > I'm reattaching the latest version of this patch with a typo fixed. > > Thanks! > > Andrea > I think the hunks in machine/ieeefp.h warrant a comment as to why we can't rely on __FLT_EVAL_METHOD__. Other than that it LGTM, but you'll need Corinna or Jeff to approve. R.