From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29971 invoked by alias); 19 Jun 2017 11:09:32 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 27365 invoked by uid 89); 19 Jun 2017 11:09:31 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.3 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=H*F:D*no, addressee, H*r:15.00.1076.000, H*RU:15.0.1076.9 X-HELO: mailgw1.ngi.no Received: from mailgw1.ngi.no (HELO mailgw1.ngi.no) (193.156.4.35) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 19 Jun 2017 11:09:28 +0000 Received: from casmbx01.oslo.ngi.no ([172.20.15.43]) by epostgw1.ngi.no with ESMTP/TLS/AES256-SHA; 19 Jun 2017 13:09:29 +0200 Received: from CASMBX02.oslo.ngi.no (172.20.15.44) by CASMBX01.oslo.ngi.no (172.20.15.43) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Mon, 19 Jun 2017 13:09:29 +0200 Received: from CASMBX02.oslo.ngi.no ([fe80::2c6f:913:5b3a:fc61]) by CASMBX02.oslo.ngi.no ([fe80::2c6f:913:5b3a:fc61%18]) with mapi id 15.00.1076.000; Mon, 19 Jun 2017 13:09:28 +0200 From: Carl Fredrik Forsberg To: "cygwin@cygwin.com" Subject: Re: bug in lrint [was: FW: Printing long int in C program under cygwin64] Date: Mon, 19 Jun 2017 11:09:00 -0000 Message-ID: <00fce7dbcc14455b891f050d7b44fe25@CASMBX02.oslo.ngi.no> x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-SW-Source: 2017-06/txt/msg00219.txt.bz2 Hello again. I have performed a few more tests with the program below. The lrint() family of functions I tested all appear tohave problems with ne= gative numbers. There seem to be an unsigned vs. signed integer problems. I could not find cygwin/math/lrint.c on my Cygwin installation where patc= hes were applied by Corinna Vinschen as discussed below. This probably ref= lects that I am not familiar with processes that go on "behind the scenes". A workaround I applied to the program was to add: #define lrint(x) (long int)(int)lrint(x) to the program. This seems to work, but I expect it will fail if all the lo= ng int digits are needed. Program: #include /* printf */ #include /* lrint */ // define statement put in here int main () { printf ( "long int -1 =3D %i\n", -1 ); printf ( "type cast -1 =3D %li\n", (long int)-1 ); printf ( "type cast lrint(-1.0) =3D %li\n", (long int)(int)lrint(-1.0) ); printf ( "rint(-1.0) =3D %f\n", rint(-1.0) ); printf ( "int of rint(-1.4)-0.5 =3D %i\n", (int)(rint(-1.4) - 0.5) ); printf ( "lrint(-1.0) =3D %li\n", lrint(-1.0) ); printf ( "lrintf(-1.0) =3D %li\n", lrintf(-1.0) ); printf ( "lrintl(-1.0) =3D %li\n", lrintl(-1.0) ); printf ( "llrintl(-1.0) =3D %lli\n", llrintl(-1.0) ); printf ( "(int)lrint(-1.0) =3D %i\n", (int)lrint(-1.0) ); printf ( "Typecasting llrint(-1.0) =3D %lli\n", (long long)(int)llrint(-1= .0) ); printf ( "lrint(1.0) =3D %li\n", lrint(1.0) ); printf ( "llrint(1.0) =3D %lli\n", llrint(1.0) ); printf ( "Type cast long long unsigned -1.0 =3D %llu\n", (unsigned long l= ong)-1 ); return 0; } /*compiled by: gcc -Wall lrint_test.c -o lrint_test.exe Result: long int -1 =3D -1 type cast -1 =3D -1 type cast lrint(-1.0) =3D -1 rint(-1.0) =3D -1.000000 int of rint(-1.4)-0.5 =3D -1 lrint(-1.0) =3D 4294967295 lrintf(-1.0) =3D 4294967295 lrintl(-1.0) =3D 4294967295 (int)lrint(-1.0) =3D -1 Typecasting llrint(-1.0) =3D -1 lrint(1.0) =3D 1 llrint(1.0) =3D 1 Type cast long long unsigned -1.0 =3D 18446744073709551615 Result with #define statement above. long int -1 =3D -1 type cast -1 =3D -1 type cast lrint(-1.0) =3D -1 rint(-1.0) =3D -1.000000 int of rint(-1.4)-0.5 =3D -1 lrint(-1.0) =3D -1 lrintf(-1.0) =3D 4294967295 lrintl(-1.0) =3D 4294967295 llrintl(-1.0) =3D 4294967295 (int)lrint(-1.0) =3D -1 Typecasting llrint(-1.0) =3D -1 lrint(1.0) =3D 1 llrint(1.0) =3D 1 Type cast long long unsigned -1.0 =3D 18446744073709551615 gcc version: gcc (GCC) 5.4.0 Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.= */ On May 24 07:33, Eric Blake wrote: > On 05/24/2017 07:00 AM, Carl Fredrik Forsberg wrote: > > type cast lrint(-1.0) =3D 4294967295 > > Now that's an interesting one - it may be that cygwin1.dll actually has > buggy behavior in lrint(). In the source code, cygwin/math/lrint.c is > dropping down to assembly; it could very well be that the assembly code > is incorrectly truncating things at 32 bits (where it is just fine for > 32-bit Cygwin, but wrong for 64-bit): > > long lrint (double x) > { > long retval =3D 0L; > #if defined(_AMD64_) || defined(__x86_64__) || defined(_X86_) || > defined(__i386__) > __asm__ __volatile__ ("fistpl %0" : "=3Dm" (retval) : "t" (x) : "st"); > #elif defined(__arm__) || defined(_ARM_) > retval =3D __lrint_internal(x); > #endif > return retval; > } > > But I'm not an assembly coding expert, so perhaps someone else will spot > the fix faster. I just applied a patch to fix this. Using fistpl is fine and dandy for Mingw because sizeof(long) =3D=3D 4, but on 64 bit Cygwin this function has to use fistpll to account for sizeof(long) =3D=3D 8. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat The confidentiality or integrity of this message can not be guaranteed foll= owing transmission on the Internet. The addressee should be aware of this b= efore using the contents of this message. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple