PATCH libffi win64 support

[Timothy Wall]

On Jun 12, 2009, at 10:20 AM, Andrew Haley wrote:

> Timothy Wall wrote:
>> applied.
>>
>> On Jun 10, 2009, at 5:45 AM, Andrew Haley wrote:
>>
>>> Timothy Wall wrote:
>>>> 2009-06-08  Timothy Wall  <twall@users.sf.net>
>>>>
>>>>    * Makefile.am,
>>>>       configure.ac,
>>>>       include/ffi.h.in,
>>>>       include/ffi_common.h,
>>>>       src/closures.c,
>>>>       src/dlmalloc.c,
>>>>       src/x86/ffi.c,
>>>>       src/x86/ffitarget.h,
>>>>       src/x86/win64.S (new),
>>>>    README: Added win64 support (mingw or MSVC)
>>>>       * ltcf-c.sh: properly escape cygwin/w32 path
>>>>       * man/ffi_call.3: Clarify size requirements for return value.
>>>>       * src/x86/ffi64.c: Fix filename in comment.
>>>
>>> Please commit this and let me know as soon as you've done so.
>
> I've got a few new test failures.  They're of the form
>
> libffi/testsuite/libffi.call/cls_align_sint64.c:80: warning: format  
> '%ld' expects type 'long int', but argument 3 has type 'long long int'
>
> It's because of changes like this:
>
> -  printf("res: %d %lld %d\n", res_dbl.a, res_dbl.b, res_dbl.c);
> +  printf("res: %d %" PRId64 " %d\n", res_dbl.a, res_dbl.b,  
> res_dbl.c);
>
> which prints out a  long long  as an int64.  This is wrong, since
> the type is "long long" and the printf format must match the
> declaration of the object being printed.

When compiling with mingw(64), the underlying runtime library doesn't  
recognize "lld" (which is what PRId64 evaluates to on my OSX), but  
rather expects "I64" or some such (properly represented by PRId64 with  
mingw).

If PRId64 is evaluating to "%ld", then perhaps that's a bug in the  
inttypes.h header.