X-Recipient: archive-cygwin AT delorie DOT com DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:from:to:subject:date:message-id:references :in-reply-to:content-type:content-transfer-encoding :mime-version; q=dns; s=default; b=egnGRcOyeN9RBFaBjWBNK6jEu+z8I ybzbuu/xvAe4ygCRRpSlxjvODvT8fupAjar1fShhfFnNNDqGDH+95zgacHLtcIYJ oxU1AyF5Xe79y1/aSjhanCM2g4AFy1oiAyirLbLNLGmyZYXiWkowwS6xuw7k7dD3 XsVd/hJT2PxogY= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:from:to:subject:date:message-id:references :in-reply-to:content-type:content-transfer-encoding :mime-version; s=default; bh=oqPApQmGecKL/PRkzQvmFDzayuI=; b=oaM 6+whuiaVJUxldSNsAlO3VgBq8tP37+z0l8XUMd6lfmMVMe9FF3GqRanC5AX4HAOt nGvqJewEno5n/gHqsrVE6d1ilCJvWr3jgGzUkF+I3EhOqe/BKmJ9HVU1GY9ONMjt t4JYfGQlDd7soMm8GpSzBr77lY76TtIVuQFcu/54= Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,CYGWIN_OWNER_BODY,GIT_PATCH_2,KAM_LAZY_DOMAIN_SECURITY,MIME_BASE64_BLANKS,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=H*F:D*no, addressee, H*M:ngi, Hx-ms-exchange-transport-fromentityheader:Hosted X-HELO: mailgw1.ngi.no From: Carl Fredrik Forsberg To: Eric Blake , "cygwin AT cygwin DOT com" Subject: RE: bug in lrint [was: FW: Printing long int in C program under cygwin64] Date: Wed, 24 May 2017 20:02:10 +0000 Message-ID: <76d59dfa226b430c8bb3a0f7a8b72e7d@CASMBX02.oslo.ngi.no> References: <6f28f46906804c6f8f6b4b861e202492 AT CASMBX02 DOT oslo DOT ngi DOT no> In-Reply-To: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by delorie.com id v4OK2S9u031858 Further to my first question, I also tried llrint() as below. It gives the same output as lrint(). This may not be a big surprise as long long int and long int have the same length. #include /* printf */ #include /* lrint, llrint, rint */ int main () { char text[64]; printf ( "type cast -1 = %li\n", (long int)-1 ); printf ( "type cast lrint(-1.0) = %li\n", (long int)lrint(-1.0) ); printf ( "rint(-1.0) = %f\n", rint(-1.0) ); printf ( "lrint(-1.0) = %li\n", lrint(-1.0) ); printf ( "llrint(-1.0) = %lli\n", llrint(-1.0) ); printf ( "lrint(1.0) = %li\n", lrint(1.0) ); printf ( "llrint(1.0) = %lli\n", llrint(1.0) ); sprintf( text,"int -1 = %i", -1 ); printf ( "Via sprintf: %s\n", text); printf ( "size of long long int: %zi\n", sizeof(long long int)); printf ( "size of long int: %zi\n", sizeof(long int)); printf ( "size of int: %zi\n", sizeof(int)); return 0; compiled by gcc -Wall lrint_test.c -o lrint_test.exe output: type cast -1 = -1 type cast lrint(-1.0) = 4294967295 rint(-1.0) = -1.000000 lrint(-1.0) = 4294967295 llrint(-1.0) = 4294967295 lrint(1.0) = 1 llrint(1.0) = 1 Via sprintf: int -1 = -1 size of long long int: 8 size of long int: 8 size of int: 4 -----Original Message----- From: cygwin-owner AT cygwin DOT com [mailto:cygwin-owner AT cygwin DOT com] On Behalf Of Eric Blake Sent: 24 May 2017 18:57 To: cygwin AT cygwin DOT com Subject: Re: bug in lrint [was: FW: Printing long int in C program under cygwin64] On 05/24/2017 11:53 AM, Erik Bray wrote: >>> 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 = 0L; >>> #if defined(_AMD64_) || defined(__x86_64__) || defined(_X86_) || >>> defined(__i386__) >>> __asm__ __volatile__ ("fistpl %0" : "=m" (retval) : "t" (x) : >>> "st"); > Actually, I take it back. gdb/objdump (and presumably binutils in > general) was being deceptive to me about the nature of that mov > instruction. And in fact the fistpl should be fistpq. That fixes it. Is fistpq right on 32-bit, or is this a case where we need different assembly for 32-bit (fistpl) vs. 64-bit (fistql) to match the size of long that we are converting to? -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org The confidentiality or integrity of this message can not be guaranteed following transmission on the Internet. The addressee should be aware of this before 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