This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Wed, May 24, 2017 at 6:57 PM, Eric Blake wrote:
> 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?

Right.  I didn't read that pre-processer line past the first couple
defines.  Really this should be fistpq on 64-bit and fistpl on 32-bit.
And if llrint has the same bug then it should be fixed there too.

The discussion about printf format specifiers is orthogonal to this.
I can submit a patch for l(l)rint if you'd like.

Erik

--
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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]