On Wed, May 24, 2017 at 5:55 PM, Erik Bray <erik.m.b...@gmail.com> wrote:
> On Wed, May 24, 2017 at 2:33 PM, Eric Blake wrote:
>> On 05/24/2017 07:00 AM, Carl Fredrik Forsberg wrote:
>>> I am experiencing problems printing long int values under cygwin64
>>> installed on a Windows 10 machine.
>>>
>>> Below is a test program followed by its output to demonstrate the problem.
>>> The program was initially written to demonstrate the output from lrint(),
>>> and developed further to demonstrate to myself how negative integers are
>>> tackled by printf type specifiers (e.g. %li, %ld etc).
>>
>> Are you compiling with -Wall, or even -Wformat?
>>
>>>
>>> My understanding is that lrint() should return a long int. However I am
>>> unable to get printf to print the correct number. Instead its output is
>>> treated as an unsigned integer.
>>> Any help or hints would be much appreciated.
>>>
>>> Regards
>>> Carl Fredrik
>>>
>>> #include <stdio.h> /* printf */
>>> #include <math.h> /* lrint */
>>>
>>> int main ()
>>> {
>>> char text[64];
>>> printf ( "int -2 = %i\n", -2 );
>>> printf ( "int -1 = %i\n", -1 );
>>> printf ( "int 0 = %i\n", 0 );
>>> printf ( "int 1 = %i\n", 1 );
>>
>> Okay so far.
>>
>>> printf ( "long int -2 = %li\n", -2 );
>>> printf ( "long int -1 = %li\n", -1 );
>>
>> Both buggy. You are passing an int through varargs, but then telling
>> printf to grab a long int. It may or may not work depending on ABI and
>> stack sizes and what not, but gcc will warn you that it is bogus.
>>
>>> printf ( "type cast -1 = %li\n", (long int)-1 );
>>> printf ( "type cast lrint(-1.0) = %li\n", (long int)lrint(-1.0) );
>>> printf ( "lrint(-1.0) = %li\n", lrint(-1.0) );
>>> printf ( "lrint(1.0) = %li\n", lrint(1.0) );
>>
>> Okay.
>>
>>> printf ( "long int 0 = %li\n", 0 );
>>> printf ( "long int 1 = %li\n", 1 );
>>> sprintf( text,"long int -1 = %li", -1 );
>>
>> Buggy.
>>
>>> printf ( "Via sprintf: %s\n", text);
>>
>> Okay (well, if you overlook the fact that text was populated in a buggy
>> manner)
>>
>>> printf ( "size of long int: %i\n", sizeof(long int));
>>> printf ( "size of int: %i\n", sizeof(int));
>>
>> Buggy. size_t should be printed with %zi, not %i (since size_t and int
>> are not necessarily the same type).
>>
>>> return 0;
>>> }
>>>
>>>
>>> compiled by:
>>> gcc lrint_test.c -o lrint_test.exe
>>
>> Missing -Wall. Also, some platforms require the use of -lm to actually
>> link with lrint() (cygwin does not, though).
>>
>>>
>>> Output:
>>>
>>> int -2 = -2
>>> int -1 = -1
>>> int 0 = 0
>>> int 1 = 1
>>> long int -2 = 4294967294
>>> long int -1 = 4294967295
>>
>> Evidence of your bugs.
>>
>>> type cast -1 = -1
>>> 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 took a look at this. The code in Cygwin looks fine, I think. But
> the assembly is wrong:
>
> 000000018015cd40 <lrint>:
> 18015cd40: 48 83 ec 28 sub $0x28,%rsp
> 18015cd44: f2 0f 11 44 24 08 movsd %xmm0,0x8(%rsp)
> 18015cd4a: dd 44 24 08 fldl 0x8(%rsp)
> 18015cd4e: db 5c 24 18 fistpl 0x18(%rsp)
> 18015cd52: 48 8b 44 24 18 mov 0x18(%rsp),%rax
> 18015cd57: 48 83 c4 28 add $0x28,%rsp
> 18015cd5b: c3 retq
>
> That last `mov` should be a `movq`. The result in $rsp+0x18 is
> correct (I checked in gdb), but the `mov` truncates it. Not sure if
> that's a gcc bug or what.
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.
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
