From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 117696 invoked by alias); 29 Jun 2017 21:17:59 -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 117662 invoked by uid 89); 29 Jun 2017 21:17:58 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: =?ISO-8859-1?Q?No, score=-0.9 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=H*r:ip*192.168.2.2, anticipation, H*r:0500, cargl=e2?= X-HELO: OARmail.OARCORP.com Received: from oarmail.oarcorp.com (HELO OARmail.OARCORP.com) (67.63.146.244) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 29 Jun 2017 21:17:56 +0000 Received: from [192.168.1.168] (192.168.1.168) by OARmail.OARCORP.com (192.168.2.2) with Microsoft SMTP Server (TLS) id 8.3.389.2; Thu, 29 Jun 2017 16:17:48 -0500 Subject: Re: Long double complex methods To: Yaakov Selkowitz , "newlib@sourceware.org" , aditya upadhyay References: <20170629063911.GB31936@calimero.vinschen.de> <20170629115309.GU6201@calimero.vinschen.de> <20170629120417.GV6201@calimero.vinschen.de> From: Joel Sherrill Message-ID: <5cff4633-2ef4-623b-e526-61c22e707d87@oarcorp.com> Date: Thu, 29 Jun 2017 21:17:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-SW-Source: 2017/txt/msg00532.txt.bz2 On 6/29/2017 2:38 PM, Yaakov Selkowitz wrote: > On 2017-06-29 07:04, Corinna Vinschen wrote: >> On Jun 29 13:53, Corinna Vinschen wrote: >>> On Jun 29 12:41, Aditya Upadhyay wrote: >>>> Hello Developers, >>>> >>>> This is the modified patch for csinl.c which reflects changes in Makefile.am. >>> >>> Uhm... this patch now contains *only* the Makefile.am change, but >>> not the expected csinl.c file. >>> >>> v3? ;) >> >> Never mind, I'm going to apply v1 and v2 of patch 18. However, usually >> a v2 (or v3, v4, ...) of a patch is expected to replace the v1 of the >> patch entirely, not that it just contains a diff to v1. >> >> I pushed the set now and regenerated complex/Makefile.in. > > This patchset is causing errors when building Cygwin: > > newlib/libm/complex/cargl.c: In function cargl’: > newlib/libm/complex/cargl.c:16:25: error: implicit declaration of > function ‘imag’ [-Werror=implicit-function-declaration] > return atan2l (imag (z), real (z)); > ^ > newlib/libm/complex/cargl.c:16:35: error: implicit declaration of > function ‘real’ [-Werror=implicit-function-declaration] > return atan2l (imag (z), real (z)); > ^ > It builds for RTEMS (sparc) with some new warnings: newlib/libm/complex/cacoshl.c:42:16: warning: implicit declaration of function 'csqrtl'; did you mean 'csqrtf'? [-Wimplicit-function-declaration] newlib/libm/complex/cacoshl.c:42:6: warning: implicit declaration of function 'clogl'; did you mean 'clogf'? [-Wimplicit-function-declaration] newlib/libm/complex/cacosl.c:41:6: warning: implicit declaration of function 'casinl'; did you mean 'asinl'? [-Wimplicit-function-declaration] newlib/libm/complex/casinhl.c:39:18: warning: implicit declaration of function 'casinl'; did you mean 'casinhl'? [-Wimplicit-function-declaration] newlib/libm/complex/casinl.c:112:7: warning: implicit declaration of function 'csqrtl'; did you mean 'sqrtl'? [-Wimplicit-function-declaration] newlib/libm/complex/casinl.c:115:7: warning: implicit declaration of function 'clogl'; did you mean 'logl'? [-Wimplicit-function-declaration] newlib/libm/complex/catanhl.c:39:18: warning: implicit declaration of function 'catanl'; did you mean 'catanhl'? [-Wimplicit-function-declaration] newlib/libm/complex/cpowl.c:47:9: warning: implicit declaration of function 'cargl'; did you mean 'cargf'? [-Wimplicit-function-declaration] I don't see any Cygwin ifdef's related to imag() so I built for i386-rtems to see if it was related to _LDBL_EQ_DBL. i386-rtems built with a few warnings. We have an x86_64-rtems tool target in anticipation of a port. I built a tool chain just to check this and the newlib master built cleanly on that. I am sorry but I am not duplicating this. What would be different about Cygwin in this case? --joel