libffi 3.0.9rc6

libffi 3.0.9rc6

[Anthony Green]

Thanks for all the feedback.  I've uploaded release candidate 6 here:

ftp://sources.redhat.com/pub/libffi/libffi-3.0.9rc6.tar.gz

It includes the missing patches identified by Andreas, Samuli, and 
Carlo.  It also includes a fix to the huge_struct test case.

And Merry Christmas to all of you celebrating today...

AG

Re: libffi 3.0.9rc6

[Andreas Tobler]

Hi Anthony!

On 25.12.09 08:11, Anthony Green wrote:
> Thanks for all the feedback.  I've uploaded release candidate 6 here:
>
> ftp://sources.redhat.com/pub/libffi/libffi-3.0.9rc6.tar.gz
>
> It includes the missing patches identified by Andreas, Samuli, and
> Carlo.  It also includes a fix to the huge_struct test case.
>
> And Merry Christmas to all of you celebrating today...

The same from my side!

There are three issues from my side:

First:

I probably was not clear about my part of the feedback. I had the 
assumption that you followed the libffi-discuss traffic.

My 'almost' complete feedback referred to this patch:

http://sources.redhat.com/ml/libffi-discuss/2009/msg00373.html

This patch is not yet in the gcc libffi tree. I hope to get it in soon.
I think it makes sense.

With almost I mean that the closures part is now also in the standalone 
libffi. So this part of the patch can also be applied now. When I wrote 
and tested the patch the closures.c part for pc-solaris was missing in 
the standalone part.
Also, an autoheader run is needed to populate the FFI_MMAP_EXEC_WRIT in 
fficonfig.h.in.

So, this part is missing in the rc6 candidate:

	* fficonfig.h.in: Regenerate.
	* src/closures.c: Remove the FFI_MMAP_EXEC_WRIT definition for
	Solaris/x86.

----
Index: src/closures.c
===================================================================
--- src/closures.c	(revision 155394)
+++ src/closures.c	(working copy)
@@ -50,11 +50,6 @@
     executable memory. */
  #  define FFI_MMAP_EXEC_WRIT 1
  # endif
-# if defined(X86_64) && defined(__sun__) && defined(__svr4__)
-/* The data segment on 64-bit Solaris/x86 isn't executable, so use mmap
-   instead.  */
-#  define FFI_MMAP_EXEC_WRIT 1
-# endif
  #endif

  #if FFI_MMAP_EXEC_WRIT && !defined FFI_MMAP_EXEC_SELINUX
----

Second:

While testing the rc6 I encountered that the install.sh is not 
executable, therefore configure will fail. chmod +x install.sh helps ;)

Third:

This huge_struct test fails under powerpc-*-linux, powerpc-*-freebsd9 
and i386-pc-solaris2.11. I will investigate.

Thank you for your patience!

Regards,
Andreas

Re: libffi 3.0.9rc6

[Anthony Green]

On 12/25/2009 03:37 PM, Andreas Tobler wrote:
> Hi Anthony!
>
> On 25.12.09 08:11, Anthony Green wrote:
>> Thanks for all the feedback.  I've uploaded release candidate 6 here:
>>
>> ftp://sources.redhat.com/pub/libffi/libffi-3.0.9rc6.tar.gz
>>
>> It includes the missing patches identified by Andreas, Samuli, and
>> Carlo.  It also includes a fix to the huge_struct test case.
>>
>> And Merry Christmas to all of you celebrating today...
>
> The same from my side!
>
> There are three issues from my side:


Ok - check out ftp://sources.redhat.com/pub/libffi/libffi-3.0.9rc7.tar.gz .


> Thank you for your patience!

Likewise :-)


AG



>
> Regards,
> Andreas

Re: libffi 3.0.9rc6

[Andreas Tobler]

On 26.12.09 06:08, Anthony Green wrote:
> On 12/25/2009 03:37 PM, Andreas Tobler wrote:
>> Hi Anthony!
>>
>> On 25.12.09 08:11, Anthony Green wrote:
>>> Thanks for all the feedback.  I've uploaded release candidate 6 here:
>>>
>>> ftp://sources.redhat.com/pub/libffi/libffi-3.0.9rc6.tar.gz
>>>
>>> It includes the missing patches identified by Andreas, Samuli, and
>>> Carlo.  It also includes a fix to the huge_struct test case.
>>>
>>> And Merry Christmas to all of you celebrating today...
>>
>> The same from my side!
>>
>> There are three issues from my side:
>
>
> Ok - check out ftp://sources.redhat.com/pub/libffi/libffi-3.0.9rc7.tar.gz .

All issues except huge_struct under solaris are resolved. See separate 
mail. I see the ppc fix is already in your repo.

Thanks,
Andreas

Re: libffi 3.0.9rc6

[Andreas Schwab]

Andreas Tobler <andreast-list@fgznet.ch> writes:

> This huge_struct test fails under powerpc-*-linux

See <http://sourceware.org/ml/libffi-discuss/2009/msg00337.html> and
<http://sourceware.org/ml/libffi-discuss/2009/msg00360.html>.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: libffi 3.0.9rc6

[Andreas Tobler]

[-- Attachment #1: Type: text/plain, Size: 779 bytes --]

On 26.12.09 11:11, Andreas Schwab wrote:
> Andreas Tobler<andreast-list@fgznet.ch>  writes:
>
>> This huge_struct test fails under powerpc-*-linux
>
> See<http://sourceware.org/ml/libffi-discuss/2009/msg00337.html>  and
> <http://sourceware.org/ml/libffi-discuss/2009/msg00360.html>.

Thank you Andreas!

With the patch mentioned above the FreeBSD and Linux PowerPC port pass 
w/o failure.

Additionally, if I apply the attached diff, I also pass the huge_struct 
test case on i386-pc-solaris2.11 and sparc-sun-solaris2.10 (It also 
passes on all other archs here.)

The issue is this, the %p modifier for printf under solaris does not add 
a leading 0x. So I modified the test case to use %#x and cast the value 
to (unsigned int). Do you think this feasible?

Thanks,
Andreas


[-- Attachment #2: huge_struct.diff --]
[-- Type: text/plain, Size: 7506 bytes --]

--- huge_struct.c.orig	2009-12-26 12:33:10.000000000 +0100
+++ huge_struct.c	2009-12-26 12:32:17.000000000 +0100
@@ -131,26 +131,26 @@
 			ui64_4 + 4, si64_4 + 4, f_4 + 4, d_4 + 4, ld_4 + 4, (char*)((intptr_t)p_4 + 4), 
 		ui8_5 + 5, si8_5 + 5};
 
-	printf("%hhu %hhd %hu %hd %u %d %" PRIu64 " %" PRId64 " %.0f %.0f %.0Lf %p "
-		"%hhu %hhd %hu %hd %u %d %" PRIu64 " %" PRId64 " %.0f %.0f %.0Lf %p "
-		"%hhu %hhd %hu %hd %u %d %" PRIu64 " %" PRId64 " %.0f %.0f %.0Lf %p "
-		"%hhu %hhd %hu %hd %u %d %" PRIu64 " %" PRId64 " %.0f %.0f %.0Lf %p %hhu %hhd: "
-		"%hhu %hhd %hu %hd %u %d %" PRIu64 " %" PRId64 " %.0f %.0f %.0Lf %p "
-		"%hhu %hhd %hu %hd %u %d %" PRIu64 " %" PRId64 " %.0f %.0f %.0Lf %p "
-		"%hhu %hhd %hu %hd %u %d %" PRIu64 " %" PRId64 " %.0f %.0f %.0Lf %p "
-		"%hhu %hhd %hu %hd %u %d %" PRIu64 " %" PRId64 " %.0f %.0f %.0Lf %p %hhu %hhd\n",
-		ui8_1, si8_1, ui16_1, si16_1, ui32_1, si32_1, ui64_1, si64_1, f_1, d_1, ld_1, p_1,
-		ui8_2, si8_2, ui16_2, si16_2, ui32_2, si32_2, ui64_2, si64_2, f_2, d_2, ld_2, p_2,
-		ui8_3, si8_3, ui16_3, si16_3, ui32_3, si32_3, ui64_3, si64_3, f_3, d_3, ld_3, p_3,
-		ui8_4, si8_4, ui16_4, si16_4, ui32_4, si32_4, ui64_4, si64_4, f_4, d_4, ld_4, p_4, ui8_5, si8_5,
+	printf("%hhu %hhd %hu %hd %u %d %" PRIu64 " %" PRId64 " %.0f %.0f %.0Lf %#x "
+		"%hhu %hhd %hu %hd %u %d %" PRIu64 " %" PRId64 " %.0f %.0f %.0Lf %#x "
+		"%hhu %hhd %hu %hd %u %d %" PRIu64 " %" PRId64 " %.0f %.0f %.0Lf %#x "
+		"%hhu %hhd %hu %hd %u %d %" PRIu64 " %" PRId64 " %.0f %.0f %.0Lf %#x %hhu %hhd: "
+		"%hhu %hhd %hu %hd %u %d %" PRIu64 " %" PRId64 " %.0f %.0f %.0Lf %#x "
+		"%hhu %hhd %hu %hd %u %d %" PRIu64 " %" PRId64 " %.0f %.0f %.0Lf %#x "
+		"%hhu %hhd %hu %hd %u %d %" PRIu64 " %" PRId64 " %.0f %.0f %.0Lf %#x "
+		"%hhu %hhd %hu %hd %u %d %" PRIu64 " %" PRId64 " %.0f %.0f %.0Lf %#x %hhu %hhd\n",
+		ui8_1, si8_1, ui16_1, si16_1, ui32_1, si32_1, ui64_1, si64_1, f_1, d_1, ld_1, (unsigned int)p_1,
+		ui8_2, si8_2, ui16_2, si16_2, ui32_2, si32_2, ui64_2, si64_2, f_2, d_2, ld_2, (unsigned int)p_2,
+		ui8_3, si8_3, ui16_3, si16_3, ui32_3, si32_3, ui64_3, si64_3, f_3, d_3, ld_3, (unsigned int)p_3,
+		ui8_4, si8_4, ui16_4, si16_4, ui32_4, si32_4, ui64_4, si64_4, f_4, d_4, ld_4, (unsigned int)p_4, ui8_5, si8_5,
 		retVal.a, retVal.b, retVal.c, retVal.d, retVal.e, retVal.f,
-		retVal.g, retVal.h, retVal.i, retVal.j, retVal.k, retVal.l,
+		retVal.g, retVal.h, retVal.i, retVal.j, retVal.k, (unsigned int)retVal.l,
 		retVal.m, retVal.n, retVal.o, retVal.p, retVal.q, retVal.r,
-		retVal.s, retVal.t, retVal.u, retVal.v, retVal.w, retVal.x,
+		retVal.s, retVal.t, retVal.u, retVal.v, retVal.w, (unsigned int)retVal.x,
 		retVal.y, retVal.z, retVal.aa, retVal.bb, retVal.cc, retVal.dd,
-		retVal.ee, retVal.ff, retVal.gg, retVal.hh, retVal.ii, retVal.jj,
+		retVal.ee, retVal.ff, retVal.gg, retVal.hh, retVal.ii, (unsigned int)retVal.jj,
 		retVal.kk, retVal.ll, retVal.mm, retVal.nn, retVal.oo, retVal.pp,
-		retVal.qq, retVal.rr, retVal.ss, retVal.tt, retVal.uu, retVal.vv, retVal.ww, retVal.xx);
+		retVal.qq, retVal.rr, retVal.ss, retVal.tt, retVal.uu, (unsigned int)retVal.vv, retVal.ww, retVal.xx);
 
 	return	retVal;
 }
@@ -298,18 +298,18 @@
 
 	ffi_call(&cif, FFI_FN(test_large_fn), &retVal, argValues);
 	// { dg-output "1 2 3 4 5 6 7 8 9 10 11 0x12345678 1 2 3 4 5 6 7 8 9 10 11 0x12345678 1 2 3 4 5 6 7 8 9 10 11 0x12345678 1 2 3 4 5 6 7 8 9 10 11 0x12345678 1 2: 2 3 4 5 6 7 8 9 10 11 12 0x12345679 3 4 5 6 7 8 9 10 11 12 13 0x1234567a 4 5 6 7 8 9 10 11 12 13 14 0x1234567b 5 6 7 8 9 10 11 12 13 14 15 0x1234567c 6 7" }
-	printf("res: %hhu %hhd %hu %hd %u %d %" PRIu64 " %" PRId64 " %.0f %.0f %.0Lf %p "
-		"%hhu %hhd %hu %hd %u %d %" PRIu64 " %" PRId64 " %.0f %.0f %.0Lf %p "
-		"%hhu %hhd %hu %hd %u %d %" PRIu64 " %" PRId64 " %.0f %.0f %.0Lf %p "
-		"%hhu %hhd %hu %hd %u %d %" PRIu64 " %" PRId64 " %.0f %.0f %.0Lf %p %hhu %hhd\n",
+	printf("res: %hhu %hhd %hu %hd %u %d %" PRIu64 " %" PRId64 " %.0f %.0f %.0Lf %#x "
+		"%hhu %hhd %hu %hd %u %d %" PRIu64 " %" PRId64 " %.0f %.0f %.0Lf %#x "
+		"%hhu %hhd %hu %hd %u %d %" PRIu64 " %" PRId64 " %.0f %.0f %.0Lf %#x "
+		"%hhu %hhd %hu %hd %u %d %" PRIu64 " %" PRId64 " %.0f %.0f %.0Lf %#x %hhu %hhd\n",
 		retVal.a, retVal.b, retVal.c, retVal.d, retVal.e, retVal.f,
-		retVal.g, retVal.h, retVal.i, retVal.j, retVal.k, retVal.l,
+		retVal.g, retVal.h, retVal.i, retVal.j, retVal.k, (unsigned int)retVal.l,
 		retVal.m, retVal.n, retVal.o, retVal.p, retVal.q, retVal.r,
-		retVal.s, retVal.t, retVal.u, retVal.v, retVal.w, retVal.x,
+		retVal.s, retVal.t, retVal.u, retVal.v, retVal.w, (unsigned int)retVal.x,
 		retVal.y, retVal.z, retVal.aa, retVal.bb, retVal.cc, retVal.dd,
-		retVal.ee, retVal.ff, retVal.gg, retVal.hh, retVal.ii, retVal.jj,
+		retVal.ee, retVal.ff, retVal.gg, retVal.hh, retVal.ii, (unsigned int)retVal.jj,
 		retVal.kk, retVal.ll, retVal.mm, retVal.nn, retVal.oo, retVal.pp,
-		retVal.qq, retVal.rr, retVal.ss, retVal.tt, retVal.uu, retVal.vv, retVal.ww, retVal.xx);
+		retVal.qq, retVal.rr, retVal.ss, retVal.tt, retVal.uu, (unsigned int)retVal.vv, retVal.ww, retVal.xx);
 	// { dg-output "\nres: 2 3 4 5 6 7 8 9 10 11 12 0x12345679 3 4 5 6 7 8 9 10 11 12 13 0x1234567a 4 5 6 7 8 9 10 11 12 13 14 0x1234567b 5 6 7 8 9 10 11 12 13 14 15 0x1234567c 6 7" }
 
 	CHECK(ffi_prep_closure_loc(pcl, &cif, cls_large_fn, NULL, code) == FFI_OK);
@@ -326,18 +326,18 @@
 		ui8, si8, ui16, si16, ui32, si32, ui64, si64, f, d, ld, p,
 		ui8, si8);
 	// { dg-output "\n1 2 3 4 5 6 7 8 9 10 11 0x12345678 1 2 3 4 5 6 7 8 9 10 11 0x12345678 1 2 3 4 5 6 7 8 9 10 11 0x12345678 1 2 3 4 5 6 7 8 9 10 11 0x12345678 1 2: 2 3 4 5 6 7 8 9 10 11 12 0x12345679 3 4 5 6 7 8 9 10 11 12 13 0x1234567a 4 5 6 7 8 9 10 11 12 13 14 0x1234567b 5 6 7 8 9 10 11 12 13 14 15 0x1234567c 6 7" }
-	printf("res: %hhu %hhd %hu %hd %u %d %" PRIu64 " %" PRId64 " %.0f %.0f %.0Lf %p "
-		"%hhu %hhd %hu %hd %u %d %" PRIu64 " %" PRId64 " %.0f %.0f %.0Lf %p "
-		"%hhu %hhd %hu %hd %u %d %" PRIu64 " %" PRId64 " %.0f %.0f %.0Lf %p "
-		"%hhu %hhd %hu %hd %u %d %" PRIu64 " %" PRId64 " %.0f %.0f %.0Lf %p %hhu %hhd\n",
+	printf("res: %hhu %hhd %hu %hd %u %d %" PRIu64 " %" PRId64 " %.0f %.0f %.0Lf %#x "
+		"%hhu %hhd %hu %hd %u %d %" PRIu64 " %" PRId64 " %.0f %.0f %.0Lf %#x "
+		"%hhu %hhd %hu %hd %u %d %" PRIu64 " %" PRId64 " %.0f %.0f %.0Lf %#x "
+		"%hhu %hhd %hu %hd %u %d %" PRIu64 " %" PRId64 " %.0f %.0f %.0Lf %#x %hhu %hhd\n",
 		retVal.a, retVal.b, retVal.c, retVal.d, retVal.e, retVal.f,
-		retVal.g, retVal.h, retVal.i, retVal.j, retVal.k, retVal.l,
+		retVal.g, retVal.h, retVal.i, retVal.j, retVal.k, (unsigned int)retVal.l,
 		retVal.m, retVal.n, retVal.o, retVal.p, retVal.q, retVal.r,
-		retVal.s, retVal.t, retVal.u, retVal.v, retVal.w, retVal.x,
+		retVal.s, retVal.t, retVal.u, retVal.v, retVal.w, (unsigned int)retVal.x,
 		retVal.y, retVal.z, retVal.aa, retVal.bb, retVal.cc, retVal.dd,
-		retVal.ee, retVal.ff, retVal.gg, retVal.hh, retVal.ii, retVal.jj,
+		retVal.ee, retVal.ff, retVal.gg, retVal.hh, retVal.ii, (unsigned int)retVal.jj,
 		retVal.kk, retVal.ll, retVal.mm, retVal.nn, retVal.oo, retVal.pp,
-		retVal.qq, retVal.rr, retVal.ss, retVal.tt, retVal.uu, retVal.vv, retVal.ww, retVal.xx);
+		retVal.qq, retVal.rr, retVal.ss, retVal.tt, retVal.uu, (unsigned int)retVal.vv, retVal.ww, retVal.xx);
 	// { dg-output "\nres: 2 3 4 5 6 7 8 9 10 11 12 0x12345679 3 4 5 6 7 8 9 10 11 12 13 0x1234567a 4 5 6 7 8 9 10 11 12 13 14 0x1234567b 5 6 7 8 9 10 11 12 13 14 15 0x1234567c 6 7" }
 
     return 0;

Re: libffi 3.0.9rc6

[Anthony Green]

[-- Attachment #1: Type: text/plain, Size: 1194 bytes --]

On 12/26/2009 06:50 AM, Andreas Tobler wrote:
> On 26.12.09 11:11, Andreas Schwab wrote:
>> Andreas Tobler<andreast-list@fgznet.ch>  writes:
>>
>>> This huge_struct test fails under powerpc-*-linux
>>
>> See<http://sourceware.org/ml/libffi-discuss/2009/msg00337.html>  and
>> <http://sourceware.org/ml/libffi-discuss/2009/msg00360.html>.
>
> Thank you Andreas!
>
> With the patch mentioned above the FreeBSD and Linux PowerPC port pass 
> w/o failure.
>
> Additionally, if I apply the attached diff, I also pass the 
> huge_struct test case on i386-pc-solaris2.11 and sparc-sun-solaris2.10 
> (It also passes on all other archs here.)
>
> The issue is this, the %p modifier for printf under solaris does not 
> add a leading 0x. So I modified the test case to use %#x and cast the 
> value to (unsigned int). Do you think this feasible?
>
> Thanks,
> Andreas
>

I had to change it to %#lx and (unsigned long) on x86-64 linux to make 
it compile cleanly.   See the attached patch.   I can test on a bunch of 
linux systems now (x86-64, powerpc, armv5tel, etc).  If you can check 
Solaris and *bsd, then I think we have a winner.

ftp://sources.redhat.com/pub/libffi/libffi-3.0.9rc8.tar.gz

AG



[-- Attachment #2: huge_struct.patch --]
[-- Type: text/plain, Size: 8100 bytes --]

2009-12-26  Andreas Tobler  <a.tobler@schweiz.org>
	    Anthony Green  <green@redhat.com>

	* testsuite/libffi.call/huge_struct.c (test_large_fn): Replace
	format code %p with %#lx because %p does not add a leading 0x on
	Solaris.  Also change relevant arguments to unsigned long.


Index: libffi/testsuite/libffi.call/huge_struct.c
===================================================================
--- libffi.orig/testsuite/libffi.call/huge_struct.c
+++ libffi/testsuite/libffi.call/huge_struct.c
@@ -131,26 +131,26 @@ test_large_fn(
 			ui64_4 + 4, si64_4 + 4, f_4 + 4, d_4 + 4, ld_4 + 4, (char*)((intptr_t)p_4 + 4), 
 		ui8_5 + 5, si8_5 + 5};
 
-	printf("%hhu %hhd %hu %hd %u %d %" PRIu64 " %" PRId64 " %.0f %.0f %.0Lf %p "
-		"%hhu %hhd %hu %hd %u %d %" PRIu64 " %" PRId64 " %.0f %.0f %.0Lf %p "
-		"%hhu %hhd %hu %hd %u %d %" PRIu64 " %" PRId64 " %.0f %.0f %.0Lf %p "
-		"%hhu %hhd %hu %hd %u %d %" PRIu64 " %" PRId64 " %.0f %.0f %.0Lf %p %hhu %hhd: "
-		"%hhu %hhd %hu %hd %u %d %" PRIu64 " %" PRId64 " %.0f %.0f %.0Lf %p "
-		"%hhu %hhd %hu %hd %u %d %" PRIu64 " %" PRId64 " %.0f %.0f %.0Lf %p "
-		"%hhu %hhd %hu %hd %u %d %" PRIu64 " %" PRId64 " %.0f %.0f %.0Lf %p "
-		"%hhu %hhd %hu %hd %u %d %" PRIu64 " %" PRId64 " %.0f %.0f %.0Lf %p %hhu %hhd\n",
-		ui8_1, si8_1, ui16_1, si16_1, ui32_1, si32_1, ui64_1, si64_1, f_1, d_1, ld_1, p_1,
-		ui8_2, si8_2, ui16_2, si16_2, ui32_2, si32_2, ui64_2, si64_2, f_2, d_2, ld_2, p_2,
-		ui8_3, si8_3, ui16_3, si16_3, ui32_3, si32_3, ui64_3, si64_3, f_3, d_3, ld_3, p_3,
-		ui8_4, si8_4, ui16_4, si16_4, ui32_4, si32_4, ui64_4, si64_4, f_4, d_4, ld_4, p_4, ui8_5, si8_5,
+	printf("%hhu %hhd %hu %hd %u %d %" PRIu64 " %" PRId64 " %.0f %.0f %.0Lf %#lx "
+		"%hhu %hhd %hu %hd %u %d %" PRIu64 " %" PRId64 " %.0f %.0f %.0Lf %#lx "
+		"%hhu %hhd %hu %hd %u %d %" PRIu64 " %" PRId64 " %.0f %.0f %.0Lf %#lx "
+		"%hhu %hhd %hu %hd %u %d %" PRIu64 " %" PRId64 " %.0f %.0f %.0Lf %#lx %hhu %hhd: "
+		"%hhu %hhd %hu %hd %u %d %" PRIu64 " %" PRId64 " %.0f %.0f %.0Lf %#lx "
+		"%hhu %hhd %hu %hd %u %d %" PRIu64 " %" PRId64 " %.0f %.0f %.0Lf %#lx "
+		"%hhu %hhd %hu %hd %u %d %" PRIu64 " %" PRId64 " %.0f %.0f %.0Lf %#lx "
+		"%hhu %hhd %hu %hd %u %d %" PRIu64 " %" PRId64 " %.0f %.0f %.0Lf %#lx %hhu %hhd\n",
+	       ui8_1, si8_1, ui16_1, si16_1, ui32_1, si32_1, ui64_1, si64_1, f_1, d_1, ld_1, (unsigned long)p_1,
+		ui8_2, si8_2, ui16_2, si16_2, ui32_2, si32_2, ui64_2, si64_2, f_2, d_2, ld_2, (unsigned long)p_2,
+		ui8_3, si8_3, ui16_3, si16_3, ui32_3, si32_3, ui64_3, si64_3, f_3, d_3, ld_3, (unsigned long)p_3,
+		ui8_4, si8_4, ui16_4, si16_4, ui32_4, si32_4, ui64_4, si64_4, f_4, d_4, ld_4, (unsigned long)p_4, ui8_5, si8_5,
 		retVal.a, retVal.b, retVal.c, retVal.d, retVal.e, retVal.f,
-		retVal.g, retVal.h, retVal.i, retVal.j, retVal.k, retVal.l,
+	       retVal.g, retVal.h, retVal.i, retVal.j, retVal.k, (unsigned long)retVal.l,
 		retVal.m, retVal.n, retVal.o, retVal.p, retVal.q, retVal.r,
-		retVal.s, retVal.t, retVal.u, retVal.v, retVal.w, retVal.x,
+	       retVal.s, retVal.t, retVal.u, retVal.v, retVal.w, (unsigned long)retVal.x,
 		retVal.y, retVal.z, retVal.aa, retVal.bb, retVal.cc, retVal.dd,
-		retVal.ee, retVal.ff, retVal.gg, retVal.hh, retVal.ii, retVal.jj,
+	       retVal.ee, retVal.ff, retVal.gg, retVal.hh, retVal.ii, (unsigned long)retVal.jj,
 		retVal.kk, retVal.ll, retVal.mm, retVal.nn, retVal.oo, retVal.pp,
-		retVal.qq, retVal.rr, retVal.ss, retVal.tt, retVal.uu, retVal.vv, retVal.ww, retVal.xx);
+	       retVal.qq, retVal.rr, retVal.ss, retVal.tt, retVal.uu, (unsigned long)retVal.vv, retVal.ww, retVal.xx);
 
 	return	retVal;
 }
@@ -298,18 +298,18 @@ main(int argc __UNUSED__, const char** a
 
 	ffi_call(&cif, FFI_FN(test_large_fn), &retVal, argValues);
 	// { dg-output "1 2 3 4 5 6 7 8 9 10 11 0x12345678 1 2 3 4 5 6 7 8 9 10 11 0x12345678 1 2 3 4 5 6 7 8 9 10 11 0x12345678 1 2 3 4 5 6 7 8 9 10 11 0x12345678 1 2: 2 3 4 5 6 7 8 9 10 11 12 0x12345679 3 4 5 6 7 8 9 10 11 12 13 0x1234567a 4 5 6 7 8 9 10 11 12 13 14 0x1234567b 5 6 7 8 9 10 11 12 13 14 15 0x1234567c 6 7" }
-	printf("res: %hhu %hhd %hu %hd %u %d %" PRIu64 " %" PRId64 " %.0f %.0f %.0Lf %p "
-		"%hhu %hhd %hu %hd %u %d %" PRIu64 " %" PRId64 " %.0f %.0f %.0Lf %p "
-		"%hhu %hhd %hu %hd %u %d %" PRIu64 " %" PRId64 " %.0f %.0f %.0Lf %p "
-		"%hhu %hhd %hu %hd %u %d %" PRIu64 " %" PRId64 " %.0f %.0f %.0Lf %p %hhu %hhd\n",
+	printf("res: %hhu %hhd %hu %hd %u %d %" PRIu64 " %" PRId64 " %.0f %.0f %.0Lf %#lx "
+		"%hhu %hhd %hu %hd %u %d %" PRIu64 " %" PRId64 " %.0f %.0f %.0Lf %#lx "
+		"%hhu %hhd %hu %hd %u %d %" PRIu64 " %" PRId64 " %.0f %.0f %.0Lf %#lx "
+		"%hhu %hhd %hu %hd %u %d %" PRIu64 " %" PRId64 " %.0f %.0f %.0Lf %#lx %hhu %hhd\n",
 		retVal.a, retVal.b, retVal.c, retVal.d, retVal.e, retVal.f,
-		retVal.g, retVal.h, retVal.i, retVal.j, retVal.k, retVal.l,
+	       retVal.g, retVal.h, retVal.i, retVal.j, retVal.k, (unsigned long)retVal.l,
 		retVal.m, retVal.n, retVal.o, retVal.p, retVal.q, retVal.r,
-		retVal.s, retVal.t, retVal.u, retVal.v, retVal.w, retVal.x,
+	       retVal.s, retVal.t, retVal.u, retVal.v, retVal.w, (unsigned long)retVal.x,
 		retVal.y, retVal.z, retVal.aa, retVal.bb, retVal.cc, retVal.dd,
-		retVal.ee, retVal.ff, retVal.gg, retVal.hh, retVal.ii, retVal.jj,
+	       retVal.ee, retVal.ff, retVal.gg, retVal.hh, retVal.ii, (unsigned long)retVal.jj,
 		retVal.kk, retVal.ll, retVal.mm, retVal.nn, retVal.oo, retVal.pp,
-		retVal.qq, retVal.rr, retVal.ss, retVal.tt, retVal.uu, retVal.vv, retVal.ww, retVal.xx);
+	       retVal.qq, retVal.rr, retVal.ss, retVal.tt, retVal.uu, (unsigned long)retVal.vv, retVal.ww, retVal.xx);
 	// { dg-output "\nres: 2 3 4 5 6 7 8 9 10 11 12 0x12345679 3 4 5 6 7 8 9 10 11 12 13 0x1234567a 4 5 6 7 8 9 10 11 12 13 14 0x1234567b 5 6 7 8 9 10 11 12 13 14 15 0x1234567c 6 7" }
 
 	CHECK(ffi_prep_closure_loc(pcl, &cif, cls_large_fn, NULL, code) == FFI_OK);
@@ -326,18 +326,18 @@ main(int argc __UNUSED__, const char** a
 		ui8, si8, ui16, si16, ui32, si32, ui64, si64, f, d, ld, p,
 		ui8, si8);
 	// { dg-output "\n1 2 3 4 5 6 7 8 9 10 11 0x12345678 1 2 3 4 5 6 7 8 9 10 11 0x12345678 1 2 3 4 5 6 7 8 9 10 11 0x12345678 1 2 3 4 5 6 7 8 9 10 11 0x12345678 1 2: 2 3 4 5 6 7 8 9 10 11 12 0x12345679 3 4 5 6 7 8 9 10 11 12 13 0x1234567a 4 5 6 7 8 9 10 11 12 13 14 0x1234567b 5 6 7 8 9 10 11 12 13 14 15 0x1234567c 6 7" }
-	printf("res: %hhu %hhd %hu %hd %u %d %" PRIu64 " %" PRId64 " %.0f %.0f %.0Lf %p "
-		"%hhu %hhd %hu %hd %u %d %" PRIu64 " %" PRId64 " %.0f %.0f %.0Lf %p "
-		"%hhu %hhd %hu %hd %u %d %" PRIu64 " %" PRId64 " %.0f %.0f %.0Lf %p "
-		"%hhu %hhd %hu %hd %u %d %" PRIu64 " %" PRId64 " %.0f %.0f %.0Lf %p %hhu %hhd\n",
+	printf("res: %hhu %hhd %hu %hd %u %d %" PRIu64 " %" PRId64 " %.0f %.0f %.0Lf %#lx "
+		"%hhu %hhd %hu %hd %u %d %" PRIu64 " %" PRId64 " %.0f %.0f %.0Lf %#lx "
+		"%hhu %hhd %hu %hd %u %d %" PRIu64 " %" PRId64 " %.0f %.0f %.0Lf %#lx "
+		"%hhu %hhd %hu %hd %u %d %" PRIu64 " %" PRId64 " %.0f %.0f %.0Lf %#lx %hhu %hhd\n",
 		retVal.a, retVal.b, retVal.c, retVal.d, retVal.e, retVal.f,
-		retVal.g, retVal.h, retVal.i, retVal.j, retVal.k, retVal.l,
+	       retVal.g, retVal.h, retVal.i, retVal.j, retVal.k, (unsigned long)retVal.l,
 		retVal.m, retVal.n, retVal.o, retVal.p, retVal.q, retVal.r,
-		retVal.s, retVal.t, retVal.u, retVal.v, retVal.w, retVal.x,
+	       retVal.s, retVal.t, retVal.u, retVal.v, retVal.w, (unsigned long)retVal.x,
 		retVal.y, retVal.z, retVal.aa, retVal.bb, retVal.cc, retVal.dd,
-		retVal.ee, retVal.ff, retVal.gg, retVal.hh, retVal.ii, retVal.jj,
+	       retVal.ee, retVal.ff, retVal.gg, retVal.hh, retVal.ii, (unsigned long)retVal.jj,
 		retVal.kk, retVal.ll, retVal.mm, retVal.nn, retVal.oo, retVal.pp,
-		retVal.qq, retVal.rr, retVal.ss, retVal.tt, retVal.uu, retVal.vv, retVal.ww, retVal.xx);
+	       retVal.qq, retVal.rr, retVal.ss, retVal.tt, retVal.uu, (unsigned long)retVal.vv, retVal.ww, retVal.xx);
 	// { dg-output "\nres: 2 3 4 5 6 7 8 9 10 11 12 0x12345679 3 4 5 6 7 8 9 10 11 12 13 0x1234567a 4 5 6 7 8 9 10 11 12 13 14 0x1234567b 5 6 7 8 9 10 11 12 13 14 15 0x1234567c 6 7" }
 
     return 0;

Re: libffi 3.0.9rc6

[Andreas Tobler]

On 26.12.09 13:37, Anthony Green wrote:
> On 12/26/2009 06:50 AM, Andreas Tobler wrote:
>> On 26.12.09 11:11, Andreas Schwab wrote:
>>> Andreas Tobler<andreast-list@fgznet.ch>   writes:
>>>
>>>> This huge_struct test fails under powerpc-*-linux
>>>
>>> See<http://sourceware.org/ml/libffi-discuss/2009/msg00337.html>   and
>>> <http://sourceware.org/ml/libffi-discuss/2009/msg00360.html>.
>>
>> Thank you Andreas!
>>
>> With the patch mentioned above the FreeBSD and Linux PowerPC port pass
>> w/o failure.
>>
>> Additionally, if I apply the attached diff, I also pass the
>> huge_struct test case on i386-pc-solaris2.11 and sparc-sun-solaris2.10
>> (It also passes on all other archs here.)
>>
>> The issue is this, the %p modifier for printf under solaris does not
>> add a leading 0x. So I modified the test case to use %#x and cast the
>> value to (unsigned int). Do you think this feasible?
>>
>> Thanks,
>> Andreas
>>
>
> I had to change it to %#lx and (unsigned long) on x86-64 linux to make
> it compile cleanly.   See the attached patch.   I can test on a bunch of
> linux systems now (x86-64, powerpc, armv5tel, etc).  If you can check
> Solaris and *bsd, then I think we have a winner.

Thank you!

amd64-unknown-freebsd9.0: ok
i386-pc-solaris2.11: ok
i386-unknown-freebsd9.0: ok
i686-apple-darwin9.8.0: ok
powerpc-apple-darwin9.8.0 failures see: (PR42378/PR34311)
powerpc-redhat-linux-gnu: ok
powerpc-unknown-freebsd9.0: ok
sparc-sun-solaris2.10: ok
(I'll add them to the wiki.)

And, another new target:)
Here it is upon you if you like to add it to 3.0.9. It is a bit boring 
here so I thought to try this one as well ;)

amd64-unknown-openbsd4.6

With these two patches (configure.ac & configure and 
testsuite/lib/libffi-dg.exp):

--- configure.ac.orig	2009-12-26 15:10:45.000000000 +0100
+++ configure.ac	2009-12-26 15:23:05.000000000 +0100
@@ -51,14 +51,10 @@
  	TARGET=ARM; TARGETDIR=arm
  	;;

-  amd64-*-freebsd*)
+  amd64-*-freebsd* | amd64-*-openbsd*)
  	TARGET=X86_64; TARGETDIR=x86
    	;;

-  amd64-*-freebsd*)
-	TARGET=X86_64; TARGETDIR=x86
-	;;
-
    avr32*-*-*)
  	TARGET=AVR32; TARGETDIR=avr32
  	;;

--- testsuite/lib/libffi-dg.exp.orig	2009-12-26 15:11:04.000000000 +0100
+++ testsuite/lib/libffi-dg.exp	2009-12-26 15:12:10.000000000 +0100
@@ -197,6 +197,10 @@
  	lappend options "libs= -shared-libgcc"
      }

+    if { [string match "*-*-openbsd*" $target_triplet] } {
+	lappend options "libs= -lpthread"
+    }
+
      lappend options "libs= -lffi"

      verbose "options: $options"



Regards,
Andreas

libffi 3.0.9 release candidate 9 - the last one??

[Anthony Green]

Ok, we're up to release candidate 9, and it's looking pretty good now!

  ftp://sources.redhat.com/pub/libffi/libffi-3.0.9rc9.tar.gz

  http://moxielogic.org/wiki/index.php?title=Libffi_3.0.9

Hosts with recent testing include:

amd64-unknown-freebsd9
amd64-unknown-openbsd4.6
armv5tel-unknown-linux-gnu
i386-pc-solaris2.11
i386-unknown-freebsd9
i686-apple-darwin9.8.0
mips64el-unknown-linux-gnu
powerpc-apple-darwin9.8.0
powerpc-redhat-linux-gnu
powerpc-unknown-linux-gnu
powerpc-unknown-freebsd9
sparc64-unknown-linux-gnu
sparc-sun-solaris2.10
x86_64-redhat-linux-gnu

Before I make the release, I'm hoping that...

   Brad can test avr32-unknown-linux-gnu
   Matthias can test s390, mips, mipsel, powerpc64, sparc and others!
   Frank can test mips-sgi-irix6.5
   Samuli can test sparc64 freebsd
   Carlo can test some windows hosts

Other testers welcome.  In particular, we have no testing coverage for 
HPPA or Alpha Linux.  Do you know anybody with access to these things?

If everything still looks good, I'll update the README and call it a day.

Thanks!

AG

Re: libffi 3.0.9 release candidate 9 - the last one??

[Samuli Suominen]

On 12/26/2009 05:35 PM, Anthony Green wrote:
> 
> Ok, we're up to release candidate 9, and it's looking pretty good now!
> 
> Before I make the release, I'm hoping that...
> 
>   Samuli can test sparc64 freebsd

I have only remote ssh connect to a linux box where I'm minicom'ing to
the sparc/fbsd machine. I'm trying to get hold of the admin so he'll
press the "Power On" switch.  :-)

> Other testers welcome.  In particular, we have no testing coverage for
> HPPA or Alpha Linux.  Do you know anybody with access to these things?

HPPA/Linux worked with 3.0.9rc3 with all tests passed per Gentoo's
pa-risc arch maintainer.

I've asked our maintainers to run tests on rc9 [1]

[1] http://bugs.gentoo.org/298322

Re: libffi 3.0.9 release candidate 9 - the last one??

[Samuli Suominen]

On 12/26/2009 05:58 PM, Samuli Suominen wrote:
>> Other testers welcome.  In particular, we have no testing coverage for
>> HPPA or Alpha Linux.  Do you know anybody with access to these things?

Alpha/Linux, it's for rc6 though

http://dev.gentoo.org/~klausman/testsuite-libffi-3.0.9_rc6-alpha.txt

		=== libffi Summary ===

# of expected passes		1624
# of expected failures		10
# of unsupported tests		15

Re: libffi 3.0.9 release candidate 9 - the last one??

[Andreas Tobler]

On 26.12.09 17:08, Andreas Tobler wrote:
> On 26.12.09 16:35, Anthony Green wrote:
>>
>> Ok, we're up to release candidate 9, and it's looking pretty good now!
>>
>>     ftp://sources.redhat.com/pub/libffi/libffi-3.0.9rc9.tar.gz
>>
>>     http://moxielogic.org/wiki/index.php?title=Libffi_3.0.9
>>
>> Hosts with recent testing include:
>>
>> amd64-unknown-freebsd9
>> amd64-unknown-openbsd4.6
>> armv5tel-unknown-linux-gnu
>> i386-pc-solaris2.11
>> i386-unknown-freebsd9
>> i686-apple-darwin9.8.0
>> mips64el-unknown-linux-gnu
>> powerpc-apple-darwin9.8.0
>> powerpc-redhat-linux-gnu
>> powerpc-unknown-linux-gnu
>> powerpc-unknown-freebsd9
>
>    sparc64-unknown-freebsd9.0
>
>> sparc64-unknown-linux-gnu
>> sparc-sun-solaris2.10
>> x86_64-redhat-linux-gnu
>>
>> Before I make the release, I'm hoping that...
>>
>>      Brad can test avr32-unknown-linux-gnu
>>      Matthias can test s390, mips, mipsel, powerpc64, sparc and others!
>>      Frank can test mips-sgi-irix6.5
>>      Samuli can test sparc64 freebsd
>>      Carlo can test some windows hosts
>>
>> Other testers welcome.  In particular, we have no testing coverage for
>> HPPA or Alpha Linux.  Do you know anybody with access to these things?
>
> I try to get my HPUX-11.11 PA box running.

This is definitely my last complaint. I have no more architectures here :)

With the below applied I can add hppa2.0w-hp-hpux11.11 to the successful 
architectures!


my PA lacks the stdint.h:

--- testsuite/libffi.call/ffitest.h.orig	2009-12-26 17:37:56.000000000 +0100
+++ testsuite/libffi.call/ffitest.h	2009-12-26 17:39:38.000000000 +0100
@@ -2,11 +2,17 @@
  #include <stdio.h>
  #include <string.h>
  #include <fcntl.h>
-#include <stdint.h>
-#include <inttypes.h>
  #include <ffi.h>
  #include "fficonfig.h"

+#if defined HAVE_STDINT_H
+#include <stdint.h>
+#endif
+
+#if defined HAVE_INTTYPES_H
+#include <inttypes.h>
+#endif
+
  #define MAX_ARGS 256

  #define CHECK(x) !(x) ? abort() : 0

Remove the stdint.h from huge_struct.c:

--- testsuite/libffi.call/huge_struct.c.orig	2009-12-26 
17:41:35.000000000 +0100
+++ testsuite/libffi.call/huge_struct.c	2009-12-26 17:41:49.000000000 +0100
@@ -10,8 +10,6 @@
  /* { dg-options -mlong-double-128 { target powerpc64*-*-* } } */
  /* { dg-output "" { xfail avr32-*-* x86_64-*-mingw* x86_64-*-cygwin* } 
} */

-#include <stdint.h>
-
  #include "ffitest.h"

  typedef	struct BigStruct{


And this one:

--- testsuite/libffi.special/unwindtest.cc.orig	2009-12-26 
17:43:40.000000000 +0100
+++ testsuite/libffi.special/unwindtest.cc	2009-12-26 17:44:20.000000000 
+0100
@@ -6,7 +6,14 @@

  /* { dg-do run } */
  #include "ffitestcxx.h"
+
+#if defined HAVE_STDINT_H
  #include <stdint.h>
+#endif
+
+#if defined HAVE_INTTYPES_H
+#include <inttypes.h>
+#endif

  void
  closure_test_fn(ffi_cif* cif __UNUSED__, void* resp __UNUSED__,

I'm really sorry that I was not able to put everything into one big 
patch, but testing needs some time. And also, a few machines I power-up 
only on demand since they are very loud.

Thanks,
Andreas

Re: libffi 3.0.9 release candidate 9 - the last one??

[Bradley Smith]

[-- Attachment #1: Type: text/plain, Size: 1106 bytes --]

On Sat, 26 Dec 2009 10:35:47 -0500
Anthony Green <green@redhat.com> wrote:

> Before I make the release, I'm hoping that...
> 
>    Brad can test avr32-unknown-linux-gnu
>    Matthias can test s390, mips, mipsel, powerpc64, sparc and others!
>    Frank can test mips-sgi-irix6.5
>    Samuli can test sparc64 freebsd
>    Carlo can test some windows hosts
> 

I've just tested this on AVR32 and there are a very few minor issues:

 1) The config.{sub,guess} files still haven't been updated, I thought
    this had already been done?

 2) The following tests need to be marked as expected failure, since they
    aren't supported:
      * libffi.call/cls_longdouble_va.c
      * libffi.call/cls_double_va.c

 3) The following tests need to be removed from expected failure as they
    work now:
      * libffi.call/huge_struct.c

Regards,
Bradley Smith

-- 
Bradley Smith                                     brad@brad-smith.co.uk
Debian GNU/Linux Developer                         bradsmith@debian.org
GPG: 0xC718D347       D201 7274 2FE1 A92A C45C EFAB 8F70 629A C718 D347

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: libffi 3.0.9 release candidate 9 - the last one??

[Anthony Green]

On 12/26/2009 12:19 PM, Bradley Smith wrote:
> On Sat, 26 Dec 2009 10:35:47 -0500
> Anthony Green<green@redhat.com>  wrote:
>
>    
>> Before I make the release, I'm hoping that...
>>
>>     Brad can test avr32-unknown-linux-gnu
>>     Matthias can test s390, mips, mipsel, powerpc64, sparc and others!
>>     Frank can test mips-sgi-irix6.5
>>     Samuli can test sparc64 freebsd
>>     Carlo can test some windows hosts
>>
>>      
> I've just tested this on AVR32 and there are a very few minor issues:
>
>   1) The config.{sub,guess} files still haven't been updated, I thought
>      this had already been done?
>
>   2) The following tests need to be marked as expected failure, since they
>      aren't supported:
>        * libffi.call/cls_longdouble_va.c
>        * libffi.call/cls_double_va.c
>
>   3) The following tests need to be removed from expected failure as they
>      work now:
>        * libffi.call/huge_struct.c
>    

Thanks Bradley.  Here's rc 10.  It also includes Andreas' HPUX fixes.

ftp://sources.redhat.com/pub/libffi/libffi-3.0.9rc10.tar.gz


AG


> Regards,
> Bradley Smith
>
>    

Re: libffi 3.0.9 release candidate 9 - the last one??

[Andreas Tobler]

On 26.12.09 20:05, Anthony Green wrote:
> On 12/26/2009 12:19 PM, Bradley Smith wrote:
>> On Sat, 26 Dec 2009 10:35:47 -0500
>> Anthony Green<green@redhat.com>   wrote:
>>
>>
>>> Before I make the release, I'm hoping that...
>>>
>>>      Brad can test avr32-unknown-linux-gnu
>>>      Matthias can test s390, mips, mipsel, powerpc64, sparc and others!
>>>      Frank can test mips-sgi-irix6.5
>>>      Samuli can test sparc64 freebsd
>>>      Carlo can test some windows hosts
>>>
>>>
>> I've just tested this on AVR32 and there are a very few minor issues:
>>
>>    1) The config.{sub,guess} files still haven't been updated, I thought
>>       this had already been done?
>>
>>    2) The following tests need to be marked as expected failure, since they
>>       aren't supported:
>>         * libffi.call/cls_longdouble_va.c
>>         * libffi.call/cls_double_va.c
>>
>>    3) The following tests need to be removed from expected failure as they
>>       work now:
>>         * libffi.call/huge_struct.c
>>
>
> Thanks Bradley.  Here's rc 10.  It also includes Andreas' HPUX fixes.
>
> ftp://sources.redhat.com/pub/libffi/libffi-3.0.9rc10.tar.gz

chmod +x install-sh ;)

Everything beside is ok, including my latest stuff (HPUX and 
amd64-*-openbsd)

Thanks!
Andreas

Re: libffi 3.0.9 release candidate 9 - the last one??

[Bradley Smith]

[-- Attachment #1: Type: text/plain, Size: 681 bytes --]

On Sat, 26 Dec 2009 14:05:45 -0500
Anthony Green <green@redhat.com> wrote:

> Thanks Bradley.  Here's rc 10.  It also includes Andreas' HPUX fixes.
> 
> ftp://sources.redhat.com/pub/libffi/libffi-3.0.9rc10.tar.gz

Sorry, I should have clarified, the cls_{long,}double_va tests fail at
output pattern testing, not execution. (Although I doubt execution is
guaranteed to pass). But other than that everything is fine :)

Regards,
Bradley Smith

-- 
Bradley Smith                                     brad@brad-smith.co.uk
Debian GNU/Linux Developer                         bradsmith@debian.org
GPG: 0xC718D347       D201 7274 2FE1 A92A C45C EFAB 8F70 629A C718 D347

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: libffi 3.0.9 release candidate 9 - the last one??

[Matthias Klose]

[-- Attachment #1: Type: text/plain, Size: 2416 bytes --]

On 26.12.2009 16:35, Anthony Green wrote:
>
> Ok, we're up to release candidate 9, and it's looking pretty good now!
>
> ftp://sources.redhat.com/pub/libffi/libffi-3.0.9rc9.tar.gz
>
> http://moxielogic.org/wiki/index.php?title=Libffi_3.0.9

> Brad can test avr32-unknown-linux-gnu
> Matthias can test s390, mips, mipsel, powerpc64, sparc and others!
> Frank can test mips-sgi-irix6.5
> Samuli can test sparc64 freebsd
> Carlo can test some windows hosts
>
> Other testers welcome. In particular, we have no testing coverage for
> HPPA or Alpha Linux. Do you know anybody with access to these things?

clean:

   hurd-i386
   {amd64,i486}-kfreebsd-gnu
   {alpha,amd64,hppa,i486,powerpc64,s390,s390x,sparc,sparc64}-linux-gnu
   arm-linux-gnueabi

mips test results will appear on
https://buildd.debian.org/build.php?arch=&pkg=libffi
the attached patch is still applied for the debian package.

powerpc-linux-gnu:

Running 
/build/buildd-libffi_3.0.9~rc9-1-powerpc-w1iphJ/libffi-3.0.9~rc9/testsuite/libffi.call/call.exp 
...
FAIL: libffi.call/cls_16byte.c -Os execution test
FAIL: libffi.call/cls_18byte.c -Os execution test
FAIL: libffi.call/cls_19byte.c -Os execution test
FAIL: libffi.call/cls_20byte.c -Os execution test
FAIL: libffi.call/cls_20byte1.c -Os execution test
FAIL: libffi.call/cls_8byte.c -Os execution test
FAIL: libffi.call/cls_9byte1.c -Os execution test
FAIL: libffi.call/cls_9byte2.c -Os execution test
FAIL: libffi.call/cls_align_double.c -Os execution test
FAIL: libffi.call/cls_align_float.c -Os execution test
WARNING: program timed out.
FAIL: libffi.call/cls_dbls_struct.c -Os execution test
FAIL: libffi.call/huge_struct.c -Os execution test
FAIL: libffi.call/nested_struct.c -Os execution test
FAIL: libffi.call/nested_struct4.c -Os execution test
FAIL: libffi.call/nested_struct6.c -Os execution test

this might due to a problem with Debian's gcc-4.4 on powerpc and -Os.

Running 
/build/buildd-libffi_3.0.9~rc9-1-armel-QM3Nky/libffi-3.0.9~rc9/testsuite/libffi.call/call.exp 
...
XPASS: libffi.call/cls_longdouble.c -O0 -W -Wall execution test
XPASS: libffi.call/cls_longdouble.c -O2 execution test
XPASS: libffi.call/cls_longdouble.c -O3 execution test
XPASS: libffi.call/cls_longdouble.c -Os execution test
XPASS: libffi.call/cls_longdouble.c -O2 -fomit-frame-pointer execution test

these pass on armv4, and armv7/thumb

I'll be not always on the computer until New Year.

   Matthias

[-- Attachment #2: libffi.diff --]
[-- Type: text/x-diff, Size: 532 bytes --]

--- libffi-3.0.9~rc9.orig/configure
+++ libffi-3.0.9~rc9/configure
@@ -12211,6 +12211,8 @@
 	TARGET=MIPS; TARGETDIR=mips
 	;;
   mips*-*-linux*)
+	# Support 128-bit long double for NewABI.
+	HAVE_LONG_DOUBLE='defined(__mips64)'
 	TARGET=MIPS; TARGETDIR=mips
 	;;
 
--- libffi-3.0.9~rc9.orig/configure.ac
+++ libffi-3.0.9~rc9/configure.ac
@@ -111,6 +111,8 @@
 	TARGET=MIPS; TARGETDIR=mips
 	;;
   mips*-*-linux*)
+	# Support 128-bit long double for NewABI.
+	HAVE_LONG_DOUBLE='defined(__mips64)'
 	TARGET=MIPS; TARGETDIR=mips
 	;;
 

Re: libffi 3.0.9 release candidate 9 - the last one??

[Anthony Green]

On 12/27/2009 07:12 PM, Matthias Klose wrote:
> On 26.12.2009 16:35, Anthony Green wrote:
>>
>> Ok, we're up to release candidate 9, and it's looking pretty good now!
>>
>> ftp://sources.redhat.com/pub/libffi/libffi-3.0.9rc9.tar.gz
>>
>> http://moxielogic.org/wiki/index.php?title=Libffi_3.0.9
>
>> Brad can test avr32-unknown-linux-gnu
>> Matthias can test s390, mips, mipsel, powerpc64, sparc and others!
>> Frank can test mips-sgi-irix6.5
>> Samuli can test sparc64 freebsd
>> Carlo can test some windows hosts
>>
>> Other testers welcome. In particular, we have no testing coverage for
>> HPPA or Alpha Linux. Do you know anybody with access to these things?
>
> clean:
>
>   hurd-i386
>   {amd64,i486}-kfreebsd-gnu
>   {alpha,amd64,hppa,i486,powerpc64,s390,s390x,sparc,sparc64}-linux-gnu
>   arm-linux-gnueabi

Thanks Matthias!

>
> mips test results will appear on
> https://buildd.debian.org/build.php?arch=&pkg=libffi
> the attached patch is still applied for the debian package.

No results yet, but I've applied your patch.

>
> powerpc-linux-gnu:
>
> Running 
> /build/buildd-libffi_3.0.9~rc9-1-powerpc-w1iphJ/libffi-3.0.9~rc9/testsuite/libffi.call/call.exp 
> ...
> FAIL: libffi.call/cls_16byte.c -Os execution test
> FAIL: libffi.call/cls_18byte.c -Os execution test
> FAIL: libffi.call/cls_19byte.c -Os execution test
> FAIL: libffi.call/cls_20byte.c -Os execution test
> FAIL: libffi.call/cls_20byte1.c -Os execution test
> FAIL: libffi.call/cls_8byte.c -Os execution test
> FAIL: libffi.call/cls_9byte1.c -Os execution test
> FAIL: libffi.call/cls_9byte2.c -Os execution test
> FAIL: libffi.call/cls_align_double.c -Os execution test
> FAIL: libffi.call/cls_align_float.c -Os execution test
> WARNING: program timed out.
> FAIL: libffi.call/cls_dbls_struct.c -Os execution test
> FAIL: libffi.call/huge_struct.c -Os execution test
> FAIL: libffi.call/nested_struct.c -Os execution test
> FAIL: libffi.call/nested_struct4.c -Os execution test
> FAIL: libffi.call/nested_struct6.c -Os execution test
>
> this might due to a problem with Debian's gcc-4.4 on powerpc and -Os.

I'm getting 0 unexpected failures on powerpc-unknown-linux-gnu with 
gcc-4.1.2.


>
> Running 
> /build/buildd-libffi_3.0.9~rc9-1-armel-QM3Nky/libffi-3.0.9~rc9/testsuite/libffi.call/call.exp 
> ...
> XPASS: libffi.call/cls_longdouble.c -O0 -W -Wall execution test
> XPASS: libffi.call/cls_longdouble.c -O2 execution test
> XPASS: libffi.call/cls_longdouble.c -O3 execution test
> XPASS: libffi.call/cls_longdouble.c -Os execution test
> XPASS: libffi.call/cls_longdouble.c -O2 -fomit-frame-pointer execution 
> test
>

I've un-xfailed these.


> these pass on armv4, and armv7/thumb
>
> I'll be not always on the computer until New Year.
>
>   Matthias

Thanks again.

AG

Re: libffi 3.0.9 release candidate 9 - the last one??

[Andreas Schwab]

Anthony Green <green@redhat.com> writes:

> I'm getting 0 unexpected failures on powerpc-unknown-linux-gnu with
> gcc-4.1.2.

Same with gcc-4.3.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: libffi 3.0.9 release candidate 9 - the last one??

[Matthias Klose]

On 28.12.2009 10:03, Andreas Schwab wrote:
> Anthony Green<green@redhat.com>  writes:
>
>> I'm getting 0 unexpected failures on powerpc-unknown-linux-gnu with
>> gcc-4.1.2.
>
> Same with gcc-4.3.

yes, no problem with 4.3.

Re: libffi 3.0.9 release candidate 9 - the last one??

[Matthias Klose]

On 28.12.2009 01:12, Matthias Klose wrote:
> On 26.12.2009 16:35, Anthony Green wrote:
>>
>> Ok, we're up to release candidate 9, and it's looking pretty good now!
>>
>> ftp://sources.redhat.com/pub/libffi/libffi-3.0.9rc9.tar.gz
>>
>> http://moxielogic.org/wiki/index.php?title=Libffi_3.0.9
>
>> Brad can test avr32-unknown-linux-gnu
>> Matthias can test s390, mips, mipsel, powerpc64, sparc and others!
>> Frank can test mips-sgi-irix6.5
>> Samuli can test sparc64 freebsd
>> Carlo can test some windows hosts
>>
>> Other testers welcome. In particular, we have no testing coverage for
>> HPPA or Alpha Linux. Do you know anybody with access to these things?
>
> clean:
>
> hurd-i386
> {amd64,i486}-kfreebsd-gnu
> {alpha,amd64,hppa,i486,powerpc64,s390,s390x,sparc,sparc64}-linux-gnu
> arm-linux-gnueabi
>
> mips test results will appear on
> https://buildd.debian.org/build.php?arch=&pkg=libffi
> the attached patch is still applied for the debian package.

https://buildd.debian.org/fetch.cgi?&pkg=libffi&ver=3.0.9~rc9-1&arch=mipsel&stamp=1262171233&file=log

clean test results for the old ABI, 10 test failures each for n32 and mips64. I 
don't have access to a mips machine.

> powerpc-linux-gnu:
>
> Running
> /build/buildd-libffi_3.0.9~rc9-1-powerpc-w1iphJ/libffi-3.0.9~rc9/testsuite/libffi.call/call.exp
> ...
> FAIL: libffi.call/cls_16byte.c -Os execution test
> FAIL: libffi.call/cls_18byte.c -Os execution test
> FAIL: libffi.call/cls_19byte.c -Os execution test
> FAIL: libffi.call/cls_20byte.c -Os execution test
> FAIL: libffi.call/cls_20byte1.c -Os execution test
> FAIL: libffi.call/cls_8byte.c -Os execution test
> FAIL: libffi.call/cls_9byte1.c -Os execution test
> FAIL: libffi.call/cls_9byte2.c -Os execution test
> FAIL: libffi.call/cls_align_double.c -Os execution test
> FAIL: libffi.call/cls_align_float.c -Os execution test
> WARNING: program timed out.
> FAIL: libffi.call/cls_dbls_struct.c -Os execution test
> FAIL: libffi.call/huge_struct.c -Os execution test
> FAIL: libffi.call/nested_struct.c -Os execution test
> FAIL: libffi.call/nested_struct4.c -Os execution test
> FAIL: libffi.call/nested_struct6.c -Os execution test
>
> this might due to a problem with Debian's gcc-4.4 on powerpc and -Os.

this problem is now fixed in Debian unstable.

   Matthias

Re: libffi 3.0.9rc6

[Dan Witte]

Tests pass for rc6, using Mozilla's automated test harness, for the following platforms:

i686-redhat-linux-gnu
i386-apple-darwin9.2.0

Our test harness heavily tests ffi_call, but not the closure or raw API.

Regards,
Dan

----- Original Message -----
From: "Anthony Green" <green@redhat.com>
To: libffi-discuss@sourceware.org
Sent: Thursday, December 24, 2009 11:11:59 PM
Subject: libffi 3.0.9rc6

Thanks for all the feedback.  I've uploaded release candidate 6 here:

ftp://sources.redhat.com/pub/libffi/libffi-3.0.9rc6.tar.gz

It includes the missing patches identified by Andreas, Samuli, and 
Carlo.  It also includes a fix to the huge_struct test case.

And Merry Christmas to all of you celebrating today...

AG