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

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

On May 24 07:33, Eric Blake wrote:
> On 05/24/2017 07:00 AM, Carl Fredrik Forsberg wrote:
> > type cast lrint(-1.0) = 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 = 0L;
> #if defined(_AMD64_) || defined(__x86_64__) || defined(_X86_) ||
> defined(__i386__)
>   __asm__ __volatile__ ("fistpl %0"  : "=m" (retval) : "t" (x) : "st");
> #elif defined(__arm__) || defined(_ARM_)
>     retval = __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) == 4, but on 64 bit Cygwin this function
has to use fistpll to account for sizeof(long) == 8.


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Attachment: signature.asc
Description: PGP signature