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

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1.1: Type: text/plain, Size: 995 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]