RE: bug in lrint [was: FW: Printing long int in C program under cygwin64]

[Carl Fredrik Forsberg <Carl.Fredrik.Forsberg@ngi.no>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 2936 bytes --]

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 <stdio.h>      /* printf */
#include <math.h>       /* 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@cygwin.com [mailto:cygwin-owner@cygwin.com] On Behalf Of Eric Blake
Sent: 24 May 2017 18:57
To: cygwin@cygwin.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.
\x03B‹KCB”\x1c›Ø›\x19[H\x1c™\^[ܝ\x1cΈ\b\b\b\b\b\b\x1a\x1d\x1d\x1c\x0e‹ËØÞYÝÚ[‹˜ÛÛKÜ\x1c›Ø›\x19[\Ëš\x1d^[[\x03B‘TNˆ\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\x1a\x1d\x1d\x1c\x0e‹ËØÞYÝÚ[‹˜ÛÛKÙ˜\KÃB‘^[ØÝ[Y[\x18]\x1a[ÛŽˆ\b\b\b\b\b\b\b\b\x1a\x1d\x1d\x1c\x0e‹ËØÞYÝÚ[‹˜ÛÛKÙ^[ØÜËš\x1d^[[\x03B•[œÝXœØÜšX™H\x1a[™›Îˆ\b\b\b\b\b\x1a\x1d\x1d\x1c\x0e‹ËØÞYÝÚ[‹˜ÛÛKÛ[\vÈÝ[œÝXœØÜšX™K\Ú[\^[\x19CBƒB