[COMMITTED] Merge libffi with upstream

[COMMITTED] Merge libffi with upstream

[Richard Henderson]

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

Upstream libffi has added support for Go closures (using the static chain),
and support for complex numbers.  Perhaps less relevant is new support for
arc, microblaze, moxie, nios, and or1k targets.

Without additional changes for Go, this merge has little effect.  Within the
gcc tree libffi is primarily used by libjava.

Tested with no regressions on {i686,x86_64,ppc64,s390x,aarch64,alpha}-linux.

Due to upstream breakage, and difficulty debugging on Darwin,
{i686,x86_64}-darwin retains copies of the existing sources and thus remains
100% unchanged.  Since libgo doesn't support darwin, this should cause no
immediate problems.


r~

[-- Attachment #2: libffi.patch.xz --]
[-- Type: application/x-xz, Size: 144788 bytes --]

Re: [COMMITTED] Merge libffi with upstream

[H.J. Lu]

On Mon, Jan 12, 2015 at 8:34 AM, Richard Henderson <rth@redhat.com> wrote:
> Upstream libffi has added support for Go closures (using the static chain),
> and support for complex numbers.  Perhaps less relevant is new support for
> arc, microblaze, moxie, nios, and or1k targets.
>
> Without additional changes for Go, this merge has little effect.  Within the
> gcc tree libffi is primarily used by libjava.
>
> Tested with no regressions on {i686,x86_64,ppc64,s390x,aarch64,alpha}-linux.
>
> Due to upstream breakage, and difficulty debugging on Darwin,
> {i686,x86_64}-darwin retains copies of the existing sources and thus remains
> 100% unchanged.  Since libgo doesn't support darwin, this should cause no
> immediate problems.
>

It caused:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64607
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64581


-- 
H.J.

Re: [COMMITTED] Merge libffi with upstream

[Rainer Orth]

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

Richard Henderson <rth@redhat.com> writes:

> Upstream libffi has added support for Go closures (using the static chain),
> and support for complex numbers.  Perhaps less relevant is new support for
> arc, microblaze, moxie, nios, and or1k targets.
>
> Without additional changes for Go, this merge has little effect.  Within the
> gcc tree libffi is primarily used by libjava.
>
> Tested with no regressions on {i686,x86_64,ppc64,s390x,aarch64,alpha}-linux.
>
> Due to upstream breakage, and difficulty debugging on Darwin,
> {i686,x86_64}-darwin retains copies of the existing sources and thus remains
> 100% unchanged.  Since libgo doesn't support darwin, this should cause no
> immediate problems.

The patch introduced massive problems on Solaris, both SPARC and x86:

* on Solaris/SPARC, /bin/as requires

  .type fn,#function

  instead of @function.  I've simply commented the affected lines in
  src/sparc/v[89].S to make progress.

* /bin/as doesn't support .macro/.endm.  I'm using preprocessor macros
  instead to implement E in src/sparc/v[89].S and src/x86/{sysv,
  unix64}.S.

* Solaris/x86 /bin/as doesn't support .org, so I've just disabled the
  uses in src/x86/{sysv, unix64}.S, as on Darwin.

* Solaris/x86 /bin/as has different COMDAT syntax; I've disabled it for
  the moment.

* Solaris/x86 needs to use EH_FRAME_FLAGS so manually and compiler
  generated .eh_frame sections match, otherwise libffi.so fails to link:

ld: fatal: file src/.libs/prep_cif.o; section [16].eh_frame and file src/x86/.libs/sysv.o; section [9].eh_frame have incompatibile attributes and cannot be merged into a single output section

* Yet unfixed for Solaris/SPARC /bin/as:

as: "v8.s", line 128: error: invalid digit in radix 10

  as seems to only understand single-digit labels

as: "v8.s", line 140: error: statement syntax
as: "v8.s", line 157: error: unknown opcode ".rept"
as: "v8.s", line 157: error: statement syntax
as: "v8.s", line 163: error: unknown opcode ".endr"
as: "v8.s", line 163: error: statement syntax

  and knows nothing about .rept/.endr

Here are the hacks I've used to make some progress:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: libffi.patch --]
[-- Type: text/x-patch, Size: 10049 bytes --]

diff --git a/libffi/src/sparc/v8.S b/libffi/src/sparc/v8.S
--- a/libffi/src/sparc/v8.S
+++ b/libffi/src/sparc/v8.S
@@ -48,7 +48,9 @@
 #ifndef __GNUC__
         .align 8
 	.globl	C(ffi_flush_icache)
+#if !(defined(__sun__) && defined(__svr4__))
 	.type	C(ffi_flush_icache),@function
+#endif
 	FFI_HIDDEN(C(ffi_flush_icache))
 
 C(ffi_flush_icache):
@@ -66,14 +68,17 @@ 1:	iflush %o0
 	.size	C(ffi_flush_icache), . - C(ffi_flush_icache)
 #endif
 
-.macro E index
-	.align	16
-	.org	2b + \index * 16
-.endm
+#if defined(__sun__) && defined(__svr4__)
+# define E(INDEX)	.align 16
+#else
+# define E(INDEX)	.align 16; .org 2b + INDEX * 16
+#endif
 
         .align 8
 	.globl	C(ffi_call_v8)
+#if !(defined(__sun__) && defined(__svr4__))
 	.type	C(ffi_call_v8),@function
+#endif
 	FFI_HIDDEN(C(ffi_call_v8))
 
 C(ffi_call_v8):
@@ -114,71 +119,71 @@ 1:	add	%o7, %l0, %o7	! o7 = 0b + ret_typ
 	! Note that each entry is 4 insns, enforced by the E macro.
 	.align	16
 2:
-E SPARC_RET_VOID
+E(SPARC_RET_VOID)
 	ret
 	 restore
-E SPARC_RET_STRUCT
+E(SPARC_RET_STRUCT)
 	unimp
-E SPARC_RET_UINT8
+E(SPARC_RET_UINT8)
 	and	%o0, 0xff, %o0
 	st	%o0, [%i2]
 	ret
 	 restore
-E SPARC_RET_SINT8
+E(SPARC_RET_SINT8)
 	sll	%o0, 24, %o0
 	b	7f
 	 sra	%o0, 24, %o0
-E SPARC_RET_UINT16
+E(SPARC_RET_UINT16)
 	sll	%o0, 16, %o0
 	b	7f
 	 srl	%o0, 16, %o0
-E SPARC_RET_SINT16
+E(SPARC_RET_SINT16)
 	sll	%o0, 16, %o0
 	b	7f
 	 sra	%o0, 16, %o0
-E SPARC_RET_UINT32
+E(SPARC_RET_UINT32)
 7:	st	%o0, [%i2]
 	ret
 	 restore
-E SP_V8_RET_CPLX16
+E(SP_V8_RET_CPLX16)
 	sth	%o0, [%i2+2]
 	b	9f
 	 srl	%o0, 16, %o0
-E SPARC_RET_INT64
+E(SPARC_RET_INT64)
 	st	%o0, [%i2]
 	st	%o1, [%i2+4]
 	ret
 	 restore
-E SPARC_RET_INT128
+E(SPARC_RET_INT128)
 	std	%o0, [%i2]
 	std	%o2, [%i2+8]
 	ret
 	 restore
-E SPARC_RET_F_8
+E(SPARC_RET_F_8)
 	st	%f7, [%i2+7*4]
 	nop
 	st	%f6, [%i2+6*4]
 	nop
-E SPARC_RET_F_6
+E(SPARC_RET_F_6)
 	st	%f5, [%i2+5*4]
 	nop
 	st	%f4, [%i2+4*4]
 	nop
-E SPARC_RET_F_4
+E(SPARC_RET_F_4)
 	st	%f3, [%i2+3*4]
 	nop
 	st	%f2, [%i2+2*4]
 	nop
-E SPARC_RET_F_2
+E(SPARC_RET_F_2)
 	st	%f1, [%i2+4]
 	st	%f0, [%i2]
 	ret
 	 restore
-E SP_V8_RET_CPLX8
+E(SP_V8_RET_CPLX8)
 	stb	%o0, [%i2+1]
 	b	10f
 	 srl	%o0, 8, %o0
-E SPARC_RET_F_1
+E(SPARC_RET_F_1)
 	st	%f0, [%i2]
 	ret
 	 restore
@@ -231,7 +236,9 @@ 2:
 
 	.align 8
 	.globl	C(ffi_go_closure_v8)
+#if !(defined(__sun__) && defined(__svr4__))
 	.type	C(ffi_go_closure_v8),@function
+#endif
 	FFI_HIDDEN(C(ffi_go_closure_v8))
 
 C(ffi_go_closure_v8):
@@ -249,7 +256,9 @@ C(ffi_go_closure_v8):
 
 	.align 8
 	.globl	C(ffi_closure_v8)
+#if !(defined(__sun__) && defined(__svr4__))
 	.type	C(ffi_closure_v8),@function
+#endif
 	FFI_HIDDEN(C(ffi_closure_v8))
 
 C(ffi_closure_v8):
@@ -285,70 +294,70 @@ 1:	sll	%o0, 4, %o0	! o0 = o0 * 16
 	! Note that each entry is 4 insns, enforced by the E macro.
 	.align	16
 2:
-E SPARC_RET_VOID
+E(SPARC_RET_VOID)
 	ret
 	 restore
-E SPARC_RET_STRUCT
+E(SPARC_RET_STRUCT)
 	ld	[%i2], %i0
 	jmp	%i7+12
 	 restore
-E SPARC_RET_UINT8
+E(SPARC_RET_UINT8)
 	ldub	[%i2+3], %i0
 	ret
 	 restore
-E SPARC_RET_SINT8
+E(SPARC_RET_SINT8)
 	ldsb	[%i2+3], %i0
 	ret
 	 restore
-E SPARC_RET_UINT16
+E(SPARC_RET_UINT16)
 	lduh	[%i2+2], %i0
 	ret
 	 restore
-E SPARC_RET_SINT16
+E(SPARC_RET_SINT16)
 	ldsh	[%i2+2], %i0
 	ret
 	 restore
-E SPARC_RET_UINT32
+E(SPARC_RET_UINT32)
 	ld	[%i2], %i0
 	ret
 	 restore
-E SP_V8_RET_CPLX16
+E(SP_V8_RET_CPLX16)
 	ld	[%i2], %i0
 	ret
 	 restore
-E SPARC_RET_INT64
+E(SPARC_RET_INT64)
 	ldd	[%i2], %i0
 	ret
 	 restore
-E SPARC_RET_INT128
+E(SPARC_RET_INT128)
 	ldd	[%i2], %i0
 	ldd	[%i2+8], %i2
 	ret
 	 restore
-E SPARC_RET_F_8
+E(SPARC_RET_F_8)
 	ld	[%i2+7*4], %f7
 	nop
 	ld	[%i2+6*4], %f6
 	nop
-E SPARC_RET_F_6
+E(SPARC_RET_F_6)
 	ld	[%i2+5*4], %f5
 	nop
 	ld	[%i2+4*4], %f4
 	nop
-E SPARC_RET_F_4
+E(SPARC_RET_F_4)
 	ld	[%i2+3*4], %f3
 	nop
 	ld	[%i2+2*4], %f2
 	nop
-E SPARC_RET_F_2
+E(SPARC_RET_F_2)
 	ldd	[%i2], %f0
 	ret
 	 restore
-E SP_V8_RET_CPLX8
+E(SP_V8_RET_CPLX8)
 	lduh	[%i2], %i0
 	ret
 	 restore
-E SPARC_RET_F_1
+E(SPARC_RET_F_1)
 	ld	[%i2], %f0
 	ret
 	 restore
diff --git a/libffi/src/sparc/v9.S b/libffi/src/sparc/v9.S
--- a/libffi/src/sparc/v9.S
+++ b/libffi/src/sparc/v9.S
@@ -42,17 +42,20 @@
 #endif
 #define L(Y)	C1(.L, Y)
 
-.macro E index
-	.align	16
-	.org	2b + \index * 16
-.endm
+#if defined(__sun__) && defined(__svr4__)
+# define E(INDEX)	.align 16
+#else
+# define E(INDEX)	.align 16; .org 2b + INDEX * 16
+#endif
 
 #define STACK_BIAS 2047
 
 	.text
         .align 8
 	.globl	C(ffi_call_v9)
+#if !(defined(__sun__) && defined(__svr4__))
 	.type	C(ffi_call_v9),@function
+#endif
 	FFI_HIDDEN(C(ffi_call_v9))
 
 C(ffi_call_v9):
@@ -107,73 +110,73 @@ 1:	sll	%l1, 4, %l1
 
 	.align	16
 2:
-E SPARC_RET_VOID
+E(SPARC_RET_VOID)
 	return	%i7+8
 	 nop
-E SPARC_RET_STRUCT
+E(SPARC_RET_STRUCT)
 	add	%sp, STACK_BIAS-64+128+48, %l2
 	sub	%sp, 64, %sp
 	b	8f
 	 stx	%o0, [%l2]
-E SPARC_RET_UINT8
+E(SPARC_RET_UINT8)
 	and	%o0, 0xff, %i0
 	return	%i7+8
 	  stx	%o0, [%o2]
-E SPARC_RET_SINT8
+E(SPARC_RET_SINT8)
 	sll	%o0, 24, %o0
 	sra	%o0, 24, %i0
 	return	%i7+8
 	 stx	%o0, [%o2]
-E SPARC_RET_UINT16
+E(SPARC_RET_UINT16)
 	sll	%o0, 16, %o0
 	srl	%o0, 16, %i0
 	return	%i7+8
 	 stx	%o0, [%o2]
-E SPARC_RET_SINT16
+E(SPARC_RET_SINT16)
 	sll	%o0, 16, %o0
 	sra	%o0, 16, %i0
 	return	%i7+8
 	 stx	%o0, [%o2]
-E SPARC_RET_UINT32
+E(SPARC_RET_UINT32)
 	srl	%o0, 0, %i0
 	return	%i7+8
 	 stx	%o0, [%o2]
-E SP_V9_RET_SINT32
+E(SP_V9_RET_SINT32)
 	sra	%o0, 0, %i0
 	return	%i7+8
 	 stx	%o0, [%o2]
-E SPARC_RET_INT64
+E(SPARC_RET_INT64)
 	stx	%o0, [%i2]
 	return	%i7+8
 	 nop
-E SPARC_RET_INT128
+E(SPARC_RET_INT128)
 	stx	%o0, [%i2]
 	stx	%o1, [%i2+8]
 	return	%i7+8
 	 nop
-E SPARC_RET_F_8
+E(SPARC_RET_F_8)
 	st	%f7, [%i2+7*4]
 	nop
 	st	%f6, [%i2+6*4]
 	nop
-E SPARC_RET_F_6
+E(SPARC_RET_F_6)
 	st	%f5, [%i2+5*4]
 	nop
 	st	%f4, [%i2+4*4]
 	nop
-E SPARC_RET_F_4
+E(SPARC_RET_F_4)
 	std	%f2, [%i2+2*4]
 	return	%i7+8
 	 std	%f0, [%o2]
-E SPARC_RET_F_2
+E(SPARC_RET_F_2)
 	return	%i7+8
 	 std	%f0, [%o2]
-E SP_V9_RET_F_3
+E(SP_V9_RET_F_3)
 	st	%f2, [%i2+2*4]
 	nop
 	st	%f1, [%i2+1*4]
 	nop
-E SPARC_RET_F_1
+E(SPARC_RET_F_1)
 	return	%i7+8
 	 st	%f0, [%o2]
 
@@ -213,7 +216,9 @@ 8:	stx	%o1, [%l2+8]
 
 	.align 8
 	.globl	C(ffi_go_closure_v9)
+#if !(defined(__sun__) && defined(__svr4__))
 	.type	C(ffi_go_closure_v9),@function
+#endif
 	FFI_HIDDEN(C(ffi_go_closure_v9))
 
 C(ffi_go_closure_v9):
@@ -232,7 +237,9 @@ C(ffi_go_closure_v9):
 
 	.align 8
 	.globl	C(ffi_closure_v9)
+#if !(defined(__sun__) && defined(__svr4__))
 	.type	C(ffi_closure_v9),@function
+#endif
 	FFI_HIDDEN(C(ffi_closure_v9))
 
 C(ffi_closure_v9):
@@ -289,72 +296,72 @@ 1:	sll	%o0, 4, %o0	! o2 = i2 * 16
 	! that is deallocated by the return.
 	.align	16
 2:
-E SPARC_RET_VOID
+E(SPARC_RET_VOID)
 	return	%i7+8
 	 nop
-E SPARC_RET_STRUCT
+E(SPARC_RET_STRUCT)
 	ldx	[FP-160], %i0
 	ldd	[FP-160], %f0
 	b	8f
 	 ldx	[FP-152], %i1
-E SPARC_RET_UINT8
+E(SPARC_RET_UINT8)
 	ldub	[FP-160+7], %i0
 	return	%i7+8
 	 nop
-E SPARC_RET_SINT8
+E(SPARC_RET_SINT8)
 	ldsb	[FP-160+7], %i0
 	return	%i7+8
 	 nop
-E SPARC_RET_UINT16
+E(SPARC_RET_UINT16)
 	lduh	[FP-160+6], %i0
 	return	%i7+8
 	 nop
-E SPARC_RET_SINT16
+E(SPARC_RET_SINT16)
 	ldsh	[FP-160+6], %i0
 	return	%i7+8
 	 nop
-E SPARC_RET_UINT32
+E(SPARC_RET_UINT32)
 	lduw	[FP-160+4], %i0
 	return	%i7+8
 	 nop
-E SP_V9_RET_SINT32
+E(SP_V9_RET_SINT32)
 	ldsw	[FP-160+4], %i0
 	return	%i7+8
 	 nop
-E SPARC_RET_INT64
+E(SPARC_RET_INT64)
 	ldx	[FP-160], %i0
 	return	%i7+8
 	 nop
-E SPARC_RET_INT128
+E(SPARC_RET_INT128)
 	ldx	[FP-160], %i0
 	ldx	[FP-160+8], %i1
 	return	%i7+8
 	 nop
-E SPARC_RET_F_8
+E(SPARC_RET_F_8)
 	ld	[FP-160+7*4], %f7
 	nop
 	ld	[FP-160+6*4], %f6
 	nop
-E SPARC_RET_F_6
+E(SPARC_RET_F_6)
 	ld	[FP-160+5*4], %f5
 	nop
 	ld	[FP-160+4*4], %f4
 	nop
-E SPARC_RET_F_4
+E(SPARC_RET_F_4)
 	ldd	[FP-160], %f0
 	ldd	[FP-160+8], %f2
 	return	%i7+8
 	 nop
-E SPARC_RET_F_2
+E(SPARC_RET_F_2)
 	ldd	[FP-160], %f0
 	return	%i7+8
 	 nop
-E SP_V9_RET_F_3
+E(SP_V9_RET_F_3)
 	ld	[FP-160+2*4], %f2
 	nop
 	ld	[FP-160+1*4], %f1
 	nop
-E SPARC_RET_F_1
+E(SPARC_RET_F_1)
 	ld	[FP-160], %f0
 	return	%i7+8
 	 nop
diff --git a/libffi/src/x86/sysv.S b/libffi/src/x86/sysv.S
--- a/libffi/src/x86/sysv.S
+++ b/libffi/src/x86/sysv.S
@@ -65,7 +65,7 @@
    actual table.  The entry points into the table are all 8 bytes.
    The use of ORG asserts that we're at the correct location.  */
 /* ??? The clang assembler doesn't handle .org with symbolic expressions.  */
-#if defined(__clang__) || defined(__APPLE__)
+#if defined(__clang__) || defined(__APPLE__) || (defined (__sun__) && defined(__svr4__))
 # define E(BASE, X)	.balign 8
 #else
 # define E(BASE, X)	.balign 8; .org BASE + X * 8
@@ -793,7 +793,7 @@ ENDF(C(ffi_closure_raw_THISCALL))
         .section __TEXT,__textcoal_nt,coalesced,pure_instructions;	\
         .weak_definition X;						\
         .private_extern X
-#elif defined __ELF__
+#elif defined __ELF__ && !(defined(__sun__) && defined(__svr4__))
 # define COMDAT(X)							\
 	.section .text.X,"axG",@progbits,X,comdat;			\
 	.globl	X;							\
@@ -823,9 +823,9 @@ ENDF(C(__x86.get_pc_thunk.dx))
 .section __TEXT,__eh_frame,coalesced,no_toc+strip_static_syms+live_support
 EHFrame0:
 #elif defined(HAVE_AS_X86_64_UNWIND_SECTION_TYPE)
-.section .eh_frame,"a",@unwind
+.section .eh_frame,EH_FRAME_FLAGS,@unwind
 #else
-.section .eh_frame,"a",@progbits
+.section .eh_frame,EH_FRAME_FLAGS,@progbits
 #endif
 
 #ifdef HAVE_AS_X86_PCREL
diff --git a/libffi/src/x86/unix64.S b/libffi/src/x86/unix64.S
--- a/libffi/src/x86/unix64.S
+++ b/libffi/src/x86/unix64.S
@@ -60,7 +60,7 @@
    actual table.  The entry points into the table are all 8 bytes.
    The use of ORG asserts that we're at the correct location.  */
 /* ??? The clang assembler doesn't handle .org with symbolic expressions.  */
-#if defined(__clang__) || defined(__APPLE__)
+#if defined(__clang__) || defined(__APPLE__) || (defined (__sun__) && defined(__svr4__))
 # define E(BASE, X)	.balign 8
 #else
 # define E(BASE, X)	.balign 8; .org BASE + X * 8

[-- Attachment #3: Type: text/plain, Size: 152 bytes --]


	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [COMMITTED] Merge libffi with upstream

[H.J. Lu]

On Thu, Jan 15, 2015 at 8:40 AM, Rainer Orth
<ro@cebitec.uni-bielefeld.de> wrote:
> Richard Henderson <rth@redhat.com> writes:
>
>> Upstream libffi has added support for Go closures (using the static chain),
>> and support for complex numbers.  Perhaps less relevant is new support for
>> arc, microblaze, moxie, nios, and or1k targets.
>>
>> Without additional changes for Go, this merge has little effect.  Within the
>> gcc tree libffi is primarily used by libjava.
>>
>> Tested with no regressions on {i686,x86_64,ppc64,s390x,aarch64,alpha}-linux.
>>
>> Due to upstream breakage, and difficulty debugging on Darwin,
>> {i686,x86_64}-darwin retains copies of the existing sources and thus remains
>> 100% unchanged.  Since libgo doesn't support darwin, this should cause no
>> immediate problems.
>
> The patch introduced massive problems on Solaris, both SPARC and x86:
>
> * on Solaris/SPARC, /bin/as requires
>
>   .type fn,#function
>
>   instead of @function.  I've simply commented the affected lines in
>   src/sparc/v[89].S to make progress.
>
> * /bin/as doesn't support .macro/.endm.  I'm using preprocessor macros
>   instead to implement E in src/sparc/v[89].S and src/x86/{sysv,
>   unix64}.S.
>
> * Solaris/x86 /bin/as doesn't support .org, so I've just disabled the
>   uses in src/x86/{sysv, unix64}.S, as on Darwin.
>
> * Solaris/x86 /bin/as has different COMDAT syntax; I've disabled it for
>   the moment.
>
> * Solaris/x86 needs to use EH_FRAME_FLAGS so manually and compiler
>   generated .eh_frame sections match, otherwise libffi.so fails to link:
>
> ld: fatal: file src/.libs/prep_cif.o; section [16].eh_frame and file src/x86/.libs/sysv.o; section [9].eh_frame have incompatibile attributes and cannot be merged into a single output section
>
> * Yet unfixed for Solaris/SPARC /bin/as:
>
> as: "v8.s", line 128: error: invalid digit in radix 10
>
>   as seems to only understand single-digit labels
>
> as: "v8.s", line 140: error: statement syntax
> as: "v8.s", line 157: error: unknown opcode ".rept"
> as: "v8.s", line 157: error: statement syntax
> as: "v8.s", line 163: error: unknown opcode ".endr"
> as: "v8.s", line 163: error: statement syntax
>
>   and knows nothing about .rept/.endr
>
> Here are the hacks I've used to make some progress:
>

I think we should

1.  Revert the libffi merge patch.
2.  Create a GCC integration branch from the merge commit
in libffi git repo
3.  Apply all GCC customization changes to the GCC integration
branch.
4. Copy the the GCC integration branch to gcc/libffi,  NOT the
unmodified libffi commit.


-- 
H.J.

Re: [COMMITTED] Merge libffi with upstream

[Richard Henderson]

On 01/15/2015 08:40 AM, Rainer Orth wrote:
> The patch introduced massive problems on Solaris, both SPARC and x86:
> 
> * on Solaris/SPARC, /bin/as requires
> 
>   .type fn,#function
> 
>   instead of @function.  I've simply commented the affected lines in
>   src/sparc/v[89].S to make progress.
> 
> * /bin/as doesn't support .macro/.endm.  I'm using preprocessor macros
>   instead to implement E in src/sparc/v[89].S and src/x86/{sysv,
>   unix64}.S.
> 
> * Solaris/x86 /bin/as doesn't support .org, so I've just disabled the
>   uses in src/x86/{sysv, unix64}.S, as on Darwin.
> 
> * Solaris/x86 /bin/as has different COMDAT syntax; I've disabled it for
>   the moment.

I hate old assemblers...

> * Solaris/x86 needs to use EH_FRAME_FLAGS so manually and compiler
>   generated .eh_frame sections match, otherwise libffi.so fails to link:

Fair enough, that's a simple error.

> as: "v8.s", line 128: error: invalid digit in radix 10
> 
>   as seems to only understand single-digit labels

Easy enough to work around, I guess.

> as: "v8.s", line 140: error: statement syntax
> as: "v8.s", line 157: error: unknown opcode ".rept"
> as: "v8.s", line 157: error: statement syntax
> as: "v8.s", line 163: error: unknown opcode ".endr"
> as: "v8.s", line 163: error: statement syntax
> 
>   and knows nothing about .rept/.endr

Ug.  More preprocessor magic, I guess.


r~

Re: [COMMITTED] Merge libffi with upstream

[Richard Henderson]

On 01/15/2015 08:54 AM, H.J. Lu wrote:
> On Thu, Jan 15, 2015 at 8:40 AM, Rainer Orth
> <ro@cebitec.uni-bielefeld.de> wrote:
>> Richard Henderson <rth@redhat.com> writes:
>>
>>> Upstream libffi has added support for Go closures (using the static chain),
>>> and support for complex numbers.  Perhaps less relevant is new support for
>>> arc, microblaze, moxie, nios, and or1k targets.
>>>
>>> Without additional changes for Go, this merge has little effect.  Within the
>>> gcc tree libffi is primarily used by libjava.
>>>
>>> Tested with no regressions on {i686,x86_64,ppc64,s390x,aarch64,alpha}-linux.
>>>
>>> Due to upstream breakage, and difficulty debugging on Darwin,
>>> {i686,x86_64}-darwin retains copies of the existing sources and thus remains
>>> 100% unchanged.  Since libgo doesn't support darwin, this should cause no
>>> immediate problems.
>>
>> The patch introduced massive problems on Solaris, both SPARC and x86:
>>
>> * on Solaris/SPARC, /bin/as requires
>>
>>   .type fn,#function
>>
>>   instead of @function.  I've simply commented the affected lines in
>>   src/sparc/v[89].S to make progress.
>>
>> * /bin/as doesn't support .macro/.endm.  I'm using preprocessor macros
>>   instead to implement E in src/sparc/v[89].S and src/x86/{sysv,
>>   unix64}.S.
>>
>> * Solaris/x86 /bin/as doesn't support .org, so I've just disabled the
>>   uses in src/x86/{sysv, unix64}.S, as on Darwin.
>>
>> * Solaris/x86 /bin/as has different COMDAT syntax; I've disabled it for
>>   the moment.
>>
>> * Solaris/x86 needs to use EH_FRAME_FLAGS so manually and compiler
>>   generated .eh_frame sections match, otherwise libffi.so fails to link:
>>
>> ld: fatal: file src/.libs/prep_cif.o; section [16].eh_frame and file src/x86/.libs/sysv.o; section [9].eh_frame have incompatibile attributes and cannot be merged into a single output section
>>
>> * Yet unfixed for Solaris/SPARC /bin/as:
>>
>> as: "v8.s", line 128: error: invalid digit in radix 10
>>
>>   as seems to only understand single-digit labels
>>
>> as: "v8.s", line 140: error: statement syntax
>> as: "v8.s", line 157: error: unknown opcode ".rept"
>> as: "v8.s", line 157: error: statement syntax
>> as: "v8.s", line 163: error: unknown opcode ".endr"
>> as: "v8.s", line 163: error: statement syntax
>>
>>   and knows nothing about .rept/.endr
>>
>> Here are the hacks I've used to make some progress:
>>
> 
> I think we should
> 
> 1.  Revert the libffi merge patch.
> 2.  Create a GCC integration branch from the merge commit
> in libffi git repo

How's that going to help?  The build infrastructure is totally different.
That and the fact that extremely few people test upstream libffi.

> 4. Copy the the GCC integration branch to gcc/libffi,  NOT the
> unmodified libffi commit.

I beg your pardon?


r~

Re: [COMMITTED] Merge libffi with upstream

[H.J. Lu]

On Thu, Jan 15, 2015 at 9:19 AM, Richard Henderson <rth@redhat.com> wrote:
> On 01/15/2015 08:54 AM, H.J. Lu wrote:
>> On Thu, Jan 15, 2015 at 8:40 AM, Rainer Orth
>> <ro@cebitec.uni-bielefeld.de> wrote:
>>> Richard Henderson <rth@redhat.com> writes:
>>>
>>>> Upstream libffi has added support for Go closures (using the static chain),
>>>> and support for complex numbers.  Perhaps less relevant is new support for
>>>> arc, microblaze, moxie, nios, and or1k targets.
>>>>
>>>> Without additional changes for Go, this merge has little effect.  Within the
>>>> gcc tree libffi is primarily used by libjava.
>>>>
>>>> Tested with no regressions on {i686,x86_64,ppc64,s390x,aarch64,alpha}-linux.
>>>>
>>>> Due to upstream breakage, and difficulty debugging on Darwin,
>>>> {i686,x86_64}-darwin retains copies of the existing sources and thus remains
>>>> 100% unchanged.  Since libgo doesn't support darwin, this should cause no
>>>> immediate problems.
>>>
>>> The patch introduced massive problems on Solaris, both SPARC and x86:
>>>
>>> * on Solaris/SPARC, /bin/as requires
>>>
>>>   .type fn,#function
>>>
>>>   instead of @function.  I've simply commented the affected lines in
>>>   src/sparc/v[89].S to make progress.
>>>
>>> * /bin/as doesn't support .macro/.endm.  I'm using preprocessor macros
>>>   instead to implement E in src/sparc/v[89].S and src/x86/{sysv,
>>>   unix64}.S.
>>>
>>> * Solaris/x86 /bin/as doesn't support .org, so I've just disabled the
>>>   uses in src/x86/{sysv, unix64}.S, as on Darwin.
>>>
>>> * Solaris/x86 /bin/as has different COMDAT syntax; I've disabled it for
>>>   the moment.
>>>
>>> * Solaris/x86 needs to use EH_FRAME_FLAGS so manually and compiler
>>>   generated .eh_frame sections match, otherwise libffi.so fails to link:
>>>
>>> ld: fatal: file src/.libs/prep_cif.o; section [16].eh_frame and file src/x86/.libs/sysv.o; section [9].eh_frame have incompatibile attributes and cannot be merged into a single output section
>>>
>>> * Yet unfixed for Solaris/SPARC /bin/as:
>>>
>>> as: "v8.s", line 128: error: invalid digit in radix 10
>>>
>>>   as seems to only understand single-digit labels
>>>
>>> as: "v8.s", line 140: error: statement syntax
>>> as: "v8.s", line 157: error: unknown opcode ".rept"
>>> as: "v8.s", line 157: error: statement syntax
>>> as: "v8.s", line 163: error: unknown opcode ".endr"
>>> as: "v8.s", line 163: error: statement syntax
>>>
>>>   and knows nothing about .rept/.endr
>>>
>>> Here are the hacks I've used to make some progress:
>>>
>>
>> I think we should
>>
>> 1.  Revert the libffi merge patch.
>> 2.  Create a GCC integration branch from the merge commit
>> in libffi git repo
>
> How's that going to help?  The build infrastructure is totally different.
> That and the fact that extremely few people test upstream libffi.

It is to make sure that all GCC customization changes don't
get lost when merging with upstream.  I am willing to work on
this and create a GCC patch to combine steps 1-4.

>> 4. Copy the the GCC integration branch to gcc/libffi,  NOT the
>> unmodified libffi commit.
>
> I beg your pardon?
>
>
> r~
>



-- 
H.J.

Re: [COMMITTED] Merge libffi with upstream

[H.J. Lu]

On Thu, Jan 15, 2015 at 8:40 AM, Rainer Orth
<ro@cebitec.uni-bielefeld.de> wrote:
> Richard Henderson <rth@redhat.com> writes:
>
>> Upstream libffi has added support for Go closures (using the static chain),
>> and support for complex numbers.  Perhaps less relevant is new support for
>> arc, microblaze, moxie, nios, and or1k targets.
>>
>> Without additional changes for Go, this merge has little effect.  Within the
>> gcc tree libffi is primarily used by libjava.
>>
>> Tested with no regressions on {i686,x86_64,ppc64,s390x,aarch64,alpha}-linux.
>>
>> Due to upstream breakage, and difficulty debugging on Darwin,
>> {i686,x86_64}-darwin retains copies of the existing sources and thus remains
>> 100% unchanged.  Since libgo doesn't support darwin, this should cause no
>> immediate problems.
>
> The patch introduced massive problems on Solaris, both SPARC and x86:
>
> * on Solaris/SPARC, /bin/as requires
>
>   .type fn,#function
>
>   instead of @function.  I've simply commented the affected lines in
>   src/sparc/v[89].S to make progress.
>
> * /bin/as doesn't support .macro/.endm.  I'm using preprocessor macros
>   instead to implement E in src/sparc/v[89].S and src/x86/{sysv,
>   unix64}.S.
>
> * Solaris/x86 /bin/as doesn't support .org, so I've just disabled the
>   uses in src/x86/{sysv, unix64}.S, as on Darwin.
>
> * Solaris/x86 /bin/as has different COMDAT syntax; I've disabled it for
>   the moment.
>
> * Solaris/x86 needs to use EH_FRAME_FLAGS so manually and compiler
>   generated .eh_frame sections match, otherwise libffi.so fails to link:
>
> ld: fatal: file src/.libs/prep_cif.o; section [16].eh_frame and file src/x86/.libs/sysv.o; section [9].eh_frame have incompatibile attributes and cannot be merged into a single output section
>
> * Yet unfixed for Solaris/SPARC /bin/as:
>
> as: "v8.s", line 128: error: invalid digit in radix 10
>
>   as seems to only understand single-digit labels
>
> as: "v8.s", line 140: error: statement syntax
> as: "v8.s", line 157: error: unknown opcode ".rept"
> as: "v8.s", line 157: error: statement syntax
> as: "v8.s", line 163: error: unknown opcode ".endr"
> as: "v8.s", line 163: error: statement syntax
>
>   and knows nothing about .rept/.endr
>
> Here are the hacks I've used to make some progress:
>

Some Sparc changes are lost in the merge.  I opened:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64618

to tract lost changes.


-- 
H.J.

Re: [COMMITTED] Merge libffi with upstream

[Richard Henderson]

On 01/15/2015 02:47 PM, H.J. Lu wrote:
> On Thu, Jan 15, 2015 at 8:40 AM, Rainer Orth
> <ro@cebitec.uni-bielefeld.de> wrote:
>> Richard Henderson <rth@redhat.com> writes:
>>
>>> Upstream libffi has added support for Go closures (using the static chain),
>>> and support for complex numbers.  Perhaps less relevant is new support for
>>> arc, microblaze, moxie, nios, and or1k targets.
>>>
>>> Without additional changes for Go, this merge has little effect.  Within the
>>> gcc tree libffi is primarily used by libjava.
>>>
>>> Tested with no regressions on {i686,x86_64,ppc64,s390x,aarch64,alpha}-linux.
>>>
>>> Due to upstream breakage, and difficulty debugging on Darwin,
>>> {i686,x86_64}-darwin retains copies of the existing sources and thus remains
>>> 100% unchanged.  Since libgo doesn't support darwin, this should cause no
>>> immediate problems.
>>
>> The patch introduced massive problems on Solaris, both SPARC and x86:
>>
>> * on Solaris/SPARC, /bin/as requires
>>
>>   .type fn,#function
>>
>>   instead of @function.  I've simply commented the affected lines in
>>   src/sparc/v[89].S to make progress.
>>
>> * /bin/as doesn't support .macro/.endm.  I'm using preprocessor macros
>>   instead to implement E in src/sparc/v[89].S and src/x86/{sysv,
>>   unix64}.S.
>>
>> * Solaris/x86 /bin/as doesn't support .org, so I've just disabled the
>>   uses in src/x86/{sysv, unix64}.S, as on Darwin.
>>
>> * Solaris/x86 /bin/as has different COMDAT syntax; I've disabled it for
>>   the moment.
>>
>> * Solaris/x86 needs to use EH_FRAME_FLAGS so manually and compiler
>>   generated .eh_frame sections match, otherwise libffi.so fails to link:
>>
>> ld: fatal: file src/.libs/prep_cif.o; section [16].eh_frame and file src/x86/.libs/sysv.o; section [9].eh_frame have incompatibile attributes and cannot be merged into a single output section
>>
>> * Yet unfixed for Solaris/SPARC /bin/as:
>>
>> as: "v8.s", line 128: error: invalid digit in radix 10
>>
>>   as seems to only understand single-digit labels
>>
>> as: "v8.s", line 140: error: statement syntax
>> as: "v8.s", line 157: error: unknown opcode ".rept"
>> as: "v8.s", line 157: error: statement syntax
>> as: "v8.s", line 163: error: unknown opcode ".endr"
>> as: "v8.s", line 163: error: statement syntax
>>
>>   and knows nothing about .rept/.endr
>>
>> Here are the hacks I've used to make some progress:
>>
> 
> Some Sparc changes are lost in the merge.  I opened:
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64618
> 
> to tract lost changes.

I'm pretty sure the sparc changes are *not* lost.
In particular, libffi 542e004710e3f1d7c137bba305a16538cd6257d6
merges back

commit be24203d712c030b4091a50f5d84b7372d5c990c
Author: ebotcazou <ebotcazou@138bc75d-0d04-0410-961f-82ee72b054a4>
Date:   Thu Feb 13 16:18:13 2014 +0000

        PR libffi/60073

listed in your new PR.

Your list of changes to libffi in the gcc tree is helpful, but
do not misconstrue all of them as missing.


r~

Re: [COMMITTED] Merge libffi with upstream

[H.J. Lu]

On Thu, Jan 15, 2015 at 3:00 PM, Richard Henderson <rth@redhat.com> wrote:
> On 01/15/2015 02:47 PM, H.J. Lu wrote:
>> On Thu, Jan 15, 2015 at 8:40 AM, Rainer Orth
>> <ro@cebitec.uni-bielefeld.de> wrote:
>>> Richard Henderson <rth@redhat.com> writes:
>>>
>>>> Upstream libffi has added support for Go closures (using the static chain),
>>>> and support for complex numbers.  Perhaps less relevant is new support for
>>>> arc, microblaze, moxie, nios, and or1k targets.
>>>>
>>>> Without additional changes for Go, this merge has little effect.  Within the
>>>> gcc tree libffi is primarily used by libjava.
>>>>
>>>> Tested with no regressions on {i686,x86_64,ppc64,s390x,aarch64,alpha}-linux.
>>>>
>>>> Due to upstream breakage, and difficulty debugging on Darwin,
>>>> {i686,x86_64}-darwin retains copies of the existing sources and thus remains
>>>> 100% unchanged.  Since libgo doesn't support darwin, this should cause no
>>>> immediate problems.
>>>
>>> The patch introduced massive problems on Solaris, both SPARC and x86:
>>>
>>> * on Solaris/SPARC, /bin/as requires
>>>
>>>   .type fn,#function
>>>
>>>   instead of @function.  I've simply commented the affected lines in
>>>   src/sparc/v[89].S to make progress.
>>>
>>> * /bin/as doesn't support .macro/.endm.  I'm using preprocessor macros
>>>   instead to implement E in src/sparc/v[89].S and src/x86/{sysv,
>>>   unix64}.S.
>>>
>>> * Solaris/x86 /bin/as doesn't support .org, so I've just disabled the
>>>   uses in src/x86/{sysv, unix64}.S, as on Darwin.
>>>
>>> * Solaris/x86 /bin/as has different COMDAT syntax; I've disabled it for
>>>   the moment.
>>>
>>> * Solaris/x86 needs to use EH_FRAME_FLAGS so manually and compiler
>>>   generated .eh_frame sections match, otherwise libffi.so fails to link:
>>>
>>> ld: fatal: file src/.libs/prep_cif.o; section [16].eh_frame and file src/x86/.libs/sysv.o; section [9].eh_frame have incompatibile attributes and cannot be merged into a single output section
>>>
>>> * Yet unfixed for Solaris/SPARC /bin/as:
>>>
>>> as: "v8.s", line 128: error: invalid digit in radix 10
>>>
>>>   as seems to only understand single-digit labels
>>>
>>> as: "v8.s", line 140: error: statement syntax
>>> as: "v8.s", line 157: error: unknown opcode ".rept"
>>> as: "v8.s", line 157: error: statement syntax
>>> as: "v8.s", line 163: error: unknown opcode ".endr"
>>> as: "v8.s", line 163: error: statement syntax
>>>
>>>   and knows nothing about .rept/.endr
>>>
>>> Here are the hacks I've used to make some progress:
>>>
>>
>> Some Sparc changes are lost in the merge.  I opened:
>>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64618
>>
>> to tract lost changes.
>
> I'm pretty sure the sparc changes are *not* lost.
> In particular, libffi 542e004710e3f1d7c137bba305a16538cd6257d6
> merges back
>
> commit be24203d712c030b4091a50f5d84b7372d5c990c
> Author: ebotcazou <ebotcazou@138bc75d-0d04-0410-961f-82ee72b054a4>
> Date:   Thu Feb 13 16:18:13 2014 +0000
>
>         PR libffi/60073
>
> listed in your new PR.
>
> Your list of changes to libffi in the gcc tree is helpful, but
> do not misconstrue all of them as missing.
>

I could have miscounted.


-- 
H.J.

Re: [COMMITTED] Merge libffi with upstream

[Rainer Orth]

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

Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> writes:

> Richard Henderson <rth@redhat.com> writes:
>
>> Upstream libffi has added support for Go closures (using the static chain),
>> and support for complex numbers.  Perhaps less relevant is new support for
>> arc, microblaze, moxie, nios, and or1k targets.
>>
>> Without additional changes for Go, this merge has little effect.  Within the
>> gcc tree libffi is primarily used by libjava.
>>
>> Tested with no regressions on {i686,x86_64,ppc64,s390x,aarch64,alpha}-linux.
>>
>> Due to upstream breakage, and difficulty debugging on Darwin,
>> {i686,x86_64}-darwin retains copies of the existing sources and thus remains
>> 100% unchanged.  Since libgo doesn't support darwin, this should cause no
>> immediate problems.
>
> The patch introduced massive problems on Solaris, both SPARC and x86:

I've noticed another issue with x86 testing: both on Solaris/x86
(i386-pc-solaris2.11) and Linux/x86 (i686-unknown-linux-gnu), many tests
fail for the 64-bit multilib:

FAIL: libffi.call/closure_simple.c -W -Wall -Wno-psabi -O0 -DABI_NUM=FFI_STDCALL -DABI_ATTR=__STDCALL__ (test for excess errors)
Excess errors:
[01m[K/vol/gcc/src/hg/trunk/local/libffi/testsuite/libffi.call/closure_simple.c:25:1:[m[K [01;35m[Kwarning: [m[K'[01m[Kstdcall[m[K' attribute ignored [-Wattributes]
 typedef int (ABI_ATTR *closure_test_type0)(int, int, int, int);
[01;32m[K ^[m[K
In file included from [01m[K/vol/gcc/src/hg/trunk/local/libffi/testsuite/libffi.call/closure_simple.c:8:0[m[K:
[01m[K/vol/gcc/src/hg/trunk/local/libffi/testsuite/libffi.call/closure_simple.c:[m[K In function '[01m[Kmain[m[K':
[01m[K<command-line>:0:9:[m[K [01;31m[Kerror: [m[K'[01m[KFFI_STDCALL[m[K' undeclared (first use in this function)
[01m[K/vol/gcc/src/hg/trunk/local/libffi/testsuite/libffi.call/ffitest.h:18:27:[m[K [01;36m[Knote: [m[Kin definition of macro '[01m[KCHECK[m[K'
 #define CHECK(x) (void)(!(x) ? (abort(), 1) : 0)
[01;32m[K                           ^[m[K
[01m[K/vol/gcc/src/hg/trunk/local/libffi/testsuite/libffi.call/closure_simple.c:42:28:[m[K [01;36m[Knote: [m[Kin expansion of macro '[01m[KABI_NUM[m[K'
   CHECK(ffi_prep_cif(&cif, ABI_NUM, 4,
[01;32m[K                            ^[m[K
[01m[K<command-line>:0:9:[m[K [01;36m[Knote: [m[Keach undeclared identifier is reported only once for each function it appears in
[01m[K/vol/gcc/src/hg/trunk/local/libffi/testsuite/libffi.call/ffitest.h:18:27:[m[K [01;36m[Knote: [m[Kin definition of macro '[01m[KCHECK[m[K'
 #define CHECK(x) (void)(!(x) ? (abort(), 1) : 0)
[01;32m[K                           ^[m[K
[01m[K/vol/gcc/src/hg/trunk/local/libffi/testsuite/libffi.call/closure_simple.c:42:28:[m[K [01;36m[Knote: [m[Kin expansion of macro '[01m[KABI_NUM[m[K'
   CHECK(ffi_prep_cif(&cif, ABI_NUM, 4,
[01;32m[K                            ^[m[K

The 32-bit x86 test in libffi.exp is bogus.  The following patch fixes
this, tested with the appropriate runtest invocation on
i386-pc-solaris2.11.  Ok for mainline?

	Rainer

2015-01-16  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>

	* testsuite/lib/libffi.exp: Load target-supports.exp.
	(run-many-tests): Only set targetabis for 32-bit x86.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: libffi-x86.patch --]
[-- Type: text/x-patch, Size: 738 bytes --]

diff --git a/libffi/testsuite/lib/libffi.exp b/libffi/testsuite/lib/libffi.exp
--- a/libffi/testsuite/lib/libffi.exp
+++ b/libffi/testsuite/lib/libffi.exp
@@ -23,6 +23,7 @@ proc load_gcc_lib { filename } {
 
 load_lib dg.exp
 load_lib libgloss.exp
+load_gcc_lib target-supports.exp
 load_gcc_lib target-libpath.exp
 load_gcc_lib wrapper.exp
 
@@ -311,7 +312,8 @@ proc run-many-tests { testcases extra_fl
 
     set targetabis { "" }
     if [string match $compiler_vendor "gnu"] {
-        if [istarget "i?86-*-*"] {
+        if { ([istarget "i?86-*-*"] || [istarget "x86_64-*-*"])
+	     && [is-effective-target ilp32] } {
             set targetabis {
                 ""
                 "-DABI_NUM=FFI_STDCALL -DABI_ATTR=__STDCALL__"

[-- Attachment #3: Type: text/plain, Size: 143 bytes --]


-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [COMMITTED] Merge libffi with upstream

[Rainer Orth]

Jakub Jelinek <jakub@redhat.com> writes:

>> @@ -311,7 +312,8 @@ proc run-many-tests { testcases extra_fl
>>  
>>      set targetabis { "" }
>>      if [string match $compiler_vendor "gnu"] {
>> -        if [istarget "i?86-*-*"] {
>> +        if { ([istarget "i?86-*-*"] || [istarget "x86_64-*-*"])
>> +	     && [is-effective-target ilp32] } {
>
> Shouldn't that be ia32 instead if ilp32 ?  I mean, do you want
> it for -mx32 too or not?

I've no idea if x32 supports stdcall or not.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [COMMITTED] Merge libffi with upstream

[Jakub Jelinek]

On Fri, Jan 16, 2015 at 02:31:25PM +0100, Rainer Orth wrote:
> 	* testsuite/lib/libffi.exp: Load target-supports.exp.
> 	(run-many-tests): Only set targetabis for 32-bit x86.
> 

> diff --git a/libffi/testsuite/lib/libffi.exp b/libffi/testsuite/lib/libffi.exp
> --- a/libffi/testsuite/lib/libffi.exp
> +++ b/libffi/testsuite/lib/libffi.exp
> @@ -23,6 +23,7 @@ proc load_gcc_lib { filename } {
>  
>  load_lib dg.exp
>  load_lib libgloss.exp
> +load_gcc_lib target-supports.exp
>  load_gcc_lib target-libpath.exp
>  load_gcc_lib wrapper.exp
>  
> @@ -311,7 +312,8 @@ proc run-many-tests { testcases extra_fl
>  
>      set targetabis { "" }
>      if [string match $compiler_vendor "gnu"] {
> -        if [istarget "i?86-*-*"] {
> +        if { ([istarget "i?86-*-*"] || [istarget "x86_64-*-*"])
> +	     && [is-effective-target ilp32] } {

Shouldn't that be ia32 instead if ilp32 ?  I mean, do you want
it for -mx32 too or not?

>              set targetabis {
>                  ""
>                  "-DABI_NUM=FFI_STDCALL -DABI_ATTR=__STDCALL__"

	Jakub

Re: [COMMITTED] Merge libffi with upstream

[H.J. Lu]

On Fri, Jan 16, 2015 at 5:38 AM, Rainer Orth
<ro@cebitec.uni-bielefeld.de> wrote:
> Jakub Jelinek <jakub@redhat.com> writes:
>
>>> @@ -311,7 +312,8 @@ proc run-many-tests { testcases extra_fl
>>>
>>>      set targetabis { "" }
>>>      if [string match $compiler_vendor "gnu"] {
>>> -        if [istarget "i?86-*-*"] {
>>> +        if { ([istarget "i?86-*-*"] || [istarget "x86_64-*-*"])
>>> +         && [is-effective-target ilp32] } {
>>
>> Shouldn't that be ia32 instead if ilp32 ?  I mean, do you want
>> it for -mx32 too or not?
>
> I've no idea if x32 supports stdcall or not.
>

No, x32 doesn't.  You should check ia32, not ilp32.

-- 
H.J.

Re: [COMMITTED] Merge libffi with upstream

[Richard Henderson]

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

On 01/15/2015 08:40 AM, Rainer Orth wrote:
> * on Solaris/SPARC, /bin/as requires
> 
>   .type fn,#function

Gas accepts this as well, so let's just use that.

> * Yet unfixed for Solaris/SPARC /bin/as:
> 
> as: "v8.s", line 128: error: invalid digit in radix 10
> 
>   as seems to only understand single-digit labels
> 
> as: "v8.s", line 140: error: statement syntax
> as: "v8.s", line 157: error: unknown opcode ".rept"
> as: "v8.s", line 157: error: statement syntax
> as: "v8.s", line 163: error: unknown opcode ".endr"
> as: "v8.s", line 163: error: statement syntax
> 
>   and knows nothing about .rept/.endr

Here's a diff of v8.S that I've just tested on linux.
That should fix the remaining problems for Solaris.


r~


[-- Attachment #2: z1 --]
[-- Type: text/plain, Size: 5446 bytes --]

diff --git a/libffi/src/sparc/v8.S b/libffi/src/sparc/v8.S
index 3a811ef..f675151 100644
--- a/libffi/src/sparc/v8.S
+++ b/libffi/src/sparc/v8.S
@@ -48,7 +48,7 @@
 #ifndef __GNUC__
         .align 8
 	.globl	C(ffi_flush_icache)
-	.type	C(ffi_flush_icache),@function
+	.type	C(ffi_flush_icache),#function
 	FFI_HIDDEN(C(ffi_flush_icache))
 
 C(ffi_flush_icache):
@@ -66,14 +66,15 @@ C(ffi_flush_icache):
 	.size	C(ffi_flush_icache), . - C(ffi_flush_icache)
 #endif
 
-.macro E index
-	.align	16
-	.org	2b + \index * 16
-.endm
+#if defined(__sun__) && defined(__svr4__)
+# define E(INDEX)	.align 16
+#else
+# define E(INDEX)	.align 16; .org 2b + INDEX * 16
+#endif
 
         .align 8
 	.globl	C(ffi_call_v8)
-	.type	C(ffi_call_v8),@function
+	.type	C(ffi_call_v8),#function
 	FFI_HIDDEN(C(ffi_call_v8))
 
 C(ffi_call_v8):
@@ -114,71 +115,71 @@ C(ffi_call_v8):
 	! Note that each entry is 4 insns, enforced by the E macro.
 	.align	16
 2:
-E SPARC_RET_VOID
+E(SPARC_RET_VOID)
 	ret
 	 restore
-E SPARC_RET_STRUCT
+E(SPARC_RET_STRUCT)
 	unimp
-E SPARC_RET_UINT8
+E(SPARC_RET_UINT8)
 	and	%o0, 0xff, %o0
 	st	%o0, [%i2]
 	ret
 	 restore
-E SPARC_RET_SINT8
+E(SPARC_RET_SINT8)
 	sll	%o0, 24, %o0
 	b	7f
 	 sra	%o0, 24, %o0
-E SPARC_RET_UINT16
+E(SPARC_RET_UINT16)
 	sll	%o0, 16, %o0
 	b	7f
 	 srl	%o0, 16, %o0
-E SPARC_RET_SINT16
+E(SPARC_RET_SINT16)
 	sll	%o0, 16, %o0
 	b	7f
 	 sra	%o0, 16, %o0
-E SPARC_RET_UINT32
+E(SPARC_RET_UINT32)
 7:	st	%o0, [%i2]
 	ret
 	 restore
-E SP_V8_RET_CPLX16
+E(SP_V8_RET_CPLX16)
 	sth	%o0, [%i2+2]
 	b	9f
 	 srl	%o0, 16, %o0
-E SPARC_RET_INT64
+E(SPARC_RET_INT64)
 	st	%o0, [%i2]
 	st	%o1, [%i2+4]
 	ret
 	 restore
-E SPARC_RET_INT128
+E(SPARC_RET_INT128)
 	std	%o0, [%i2]
 	std	%o2, [%i2+8]
 	ret
 	 restore
-E SPARC_RET_F_8
+E(SPARC_RET_F_8)
 	st	%f7, [%i2+7*4]
 	nop
 	st	%f6, [%i2+6*4]
 	nop
-E SPARC_RET_F_6
+E(SPARC_RET_F_6)
 	st	%f5, [%i2+5*4]
 	nop
 	st	%f4, [%i2+4*4]
 	nop
-E SPARC_RET_F_4
+E(SPARC_RET_F_4)
 	st	%f3, [%i2+3*4]
 	nop
 	st	%f2, [%i2+2*4]
 	nop
-E SPARC_RET_F_2
+E(SPARC_RET_F_2)
 	st	%f1, [%i2+4]
 	st	%f0, [%i2]
 	ret
 	 restore
-E SP_V8_RET_CPLX8
+E(SP_V8_RET_CPLX8)
 	stb	%o0, [%i2+1]
-	b	10f
+	b	0f
 	 srl	%o0, 8, %o0
-E SPARC_RET_F_1
+E(SPARC_RET_F_1)
 	st	%f0, [%i2]
 	ret
 	 restore
@@ -188,7 +189,7 @@ E SPARC_RET_F_1
 	ret
 	 restore
 	.align	8
-10:	stb	%o0, [%i2]
+0:	stb	%o0, [%i2]
 	ret
 	 restore
 
@@ -201,17 +202,35 @@ E SPARC_RET_F_1
 	 sll	%l1, 2, %l0			! size * 4
 1:	sll	%l1, 4, %l1			! size * 16
 	add	%l0, %l1, %l0			! size * 20
-	add	%o7, %l0, %o7			! o7 = 0b + size*20
+	add	%o7, %l0, %o7			! o7 = 8b + size*20
 	jmp	%o7+(2f-8b)
 	 mov	%i5, %g2			! load static chain
 2:
-.rept	0x1000
-	call	%i1
-	 nop
-	unimp	(. - 2b) / 20
-	ret
+
+/* The Sun assembler doesn't understand .rept 0x1000.  */
+#define rept1			\
+	call	%i1;		\
+	 nop;			\
+	unimp	(. - 2b) / 20;	\
+	ret;			\
 	 restore
-.endr
+
+#define rept16				\
+	rept1; rept1; rept1; rept1;	\
+	rept1; rept1; rept1; rept1;	\
+	rept1; rept1; rept1; rept1;	\
+	rept1; rept1; rept1; rept1
+
+#define rept256				\
+	rept16; rept16; rept16; rept16;	\
+	rept16; rept16; rept16; rept16;	\
+	rept16; rept16; rept16; rept16;	\
+	rept16; rept16; rept16; rept16
+
+	rept256; rept256; rept256; rept256
+	rept256; rept256; rept256; rept256
+	rept256; rept256; rept256; rept256
+	rept256; rept256; rept256; rept256
 
 	cfi_endproc
 	.size	C(ffi_call_v8),. - C(ffi_call_v8)
@@ -231,7 +250,7 @@ E SPARC_RET_F_1
 
 	.align 8
 	.globl	C(ffi_go_closure_v8)
-	.type	C(ffi_go_closure_v8),@function
+	.type	C(ffi_go_closure_v8),#function
 	FFI_HIDDEN(C(ffi_go_closure_v8))
 
 C(ffi_go_closure_v8):
@@ -249,7 +268,7 @@ C(ffi_go_closure_v8):
 
 	.align 8
 	.globl	C(ffi_closure_v8)
-	.type	C(ffi_closure_v8),@function
+	.type	C(ffi_closure_v8),#function
 	FFI_HIDDEN(C(ffi_closure_v8))
 
 C(ffi_closure_v8):
@@ -285,70 +304,70 @@ C(ffi_closure_v8):
 	! Note that each entry is 4 insns, enforced by the E macro.
 	.align	16
 2:
-E SPARC_RET_VOID
+E(SPARC_RET_VOID)
 	ret
 	 restore
-E SPARC_RET_STRUCT
+E(SPARC_RET_STRUCT)
 	ld	[%i2], %i0
 	jmp	%i7+12
 	 restore
-E SPARC_RET_UINT8
+E(SPARC_RET_UINT8)
 	ldub	[%i2+3], %i0
 	ret
 	 restore
-E SPARC_RET_SINT8
+E(SPARC_RET_SINT8)
 	ldsb	[%i2+3], %i0
 	ret
 	 restore
-E SPARC_RET_UINT16
+E(SPARC_RET_UINT16)
 	lduh	[%i2+2], %i0
 	ret
 	 restore
-E SPARC_RET_SINT16
+E(SPARC_RET_SINT16)
 	ldsh	[%i2+2], %i0
 	ret
 	 restore
-E SPARC_RET_UINT32
+E(SPARC_RET_UINT32)
 	ld	[%i2], %i0
 	ret
 	 restore
-E SP_V8_RET_CPLX16
+E(SP_V8_RET_CPLX16)
 	ld	[%i2], %i0
 	ret
 	 restore
-E SPARC_RET_INT64
+E(SPARC_RET_INT64)
 	ldd	[%i2], %i0
 	ret
 	 restore
-E SPARC_RET_INT128
+E(SPARC_RET_INT128)
 	ldd	[%i2], %i0
 	ldd	[%i2+8], %i2
 	ret
 	 restore
-E SPARC_RET_F_8
+E(SPARC_RET_F_8)
 	ld	[%i2+7*4], %f7
 	nop
 	ld	[%i2+6*4], %f6
 	nop
-E SPARC_RET_F_6
+E(SPARC_RET_F_6)
 	ld	[%i2+5*4], %f5
 	nop
 	ld	[%i2+4*4], %f4
 	nop
-E SPARC_RET_F_4
+E(SPARC_RET_F_4)
 	ld	[%i2+3*4], %f3
 	nop
 	ld	[%i2+2*4], %f2
 	nop
-E SPARC_RET_F_2
+E(SPARC_RET_F_2)
 	ldd	[%i2], %f0
 	ret
 	 restore
-E SP_V8_RET_CPLX8
+E(SP_V8_RET_CPLX8)
 	lduh	[%i2], %i0
 	ret
 	 restore
-E SPARC_RET_F_1
+E(SPARC_RET_F_1)
 	ld	[%i2], %f0
 	ret
 	 restore

Re: [COMMITTED] Merge libffi with upstream

[Rainer Orth]

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

"H.J. Lu" <hjl.tools@gmail.com> writes:

> On Fri, Jan 16, 2015 at 5:38 AM, Rainer Orth
> <ro@cebitec.uni-bielefeld.de> wrote:
>> Jakub Jelinek <jakub@redhat.com> writes:
>>
>>>> @@ -311,7 +312,8 @@ proc run-many-tests { testcases extra_fl
>>>>
>>>>      set targetabis { "" }
>>>>      if [string match $compiler_vendor "gnu"] {
>>>> -        if [istarget "i?86-*-*"] {
>>>> +        if { ([istarget "i?86-*-*"] || [istarget "x86_64-*-*"])
>>>> +         && [is-effective-target ilp32] } {
>>>
>>> Shouldn't that be ia32 instead if ilp32 ?  I mean, do you want
>>> it for -mx32 too or not?
>>
>> I've no idea if x32 supports stdcall or not.
>
> No, x32 doesn't.  You should check ia32, not ilp32.

2015-01-16  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>

	* testsuite/lib/libffi.exp: Load target-supports.exp.
	(run-many-tests): Only set targetabis for ia32.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: libffi-32-bit-x86.patch --]
[-- Type: text/x-patch, Size: 840 bytes --]

# HG changeset patch
# Parent 5b70ffc67684f61ff23547e4b3ad25e64a2ca2a2
Correctly check for 32-bit x86

diff --git a/libffi/testsuite/lib/libffi.exp b/libffi/testsuite/lib/libffi.exp
--- a/libffi/testsuite/lib/libffi.exp
+++ b/libffi/testsuite/lib/libffi.exp
@@ -23,6 +23,7 @@ proc load_gcc_lib { filename } {
 
 load_lib dg.exp
 load_lib libgloss.exp
+load_gcc_lib target-supports.exp
 load_gcc_lib target-libpath.exp
 load_gcc_lib wrapper.exp
 
@@ -311,7 +312,8 @@ proc run-many-tests { testcases extra_fl
 
     set targetabis { "" }
     if [string match $compiler_vendor "gnu"] {
-        if [istarget "i?86-*-*"] {
+        if { ([istarget "i?86-*-*"] || [istarget "x86_64-*-*"])
+	     && [is-effective-target ia32] } {
             set targetabis {
                 ""
                 "-DABI_NUM=FFI_STDCALL -DABI_ATTR=__STDCALL__"

[-- Attachment #3: Type: text/plain, Size: 209 bytes --]


This patch worked for me.  Ok for mainline now?

Thanks.
	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [COMMITTED] Merge libffi with upstream

[Richard Henderson]

On 01/26/2015 06:19 AM, Rainer Orth wrote:
> 2015-01-16  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>
> 
> 	* testsuite/lib/libffi.exp: Load target-supports.exp.
> 	(run-many-tests): Only set targetabis for ia32.

Ok.


r~

Re: [COMMITTED] Merge libffi with upstream

[Iain Sandoe]

On 29 Jan 2015, at 16:22, Richard Henderson wrote:
>> 
>> Well, somewhat confusingly "x86/darwin_c.c" is shared between darwin and the various Windows 32 bit implementations.
> 
> It's not shared with anything.  It's a copy of the old x86/ffi.c
> prior to the merge from upstream.

yeah, I get it now - and agreed about your comment in PR64855, the place to invest effort is in fixing it upstream (duly added to the list of Darwin project opportunities ;) )
Iain

Re: [COMMITTED] Merge libffi with upstream

[Richard Henderson]

On 01/29/2015 01:10 AM, Iain Sandoe wrote:
> 
> On 28 Jan 2015, at 18:16, Richard Henderson wrote:
> 
>> On 01/28/2015 10:10 AM, Dominique d'Humières wrote:
>>>> I can't think of any reason they shouldn't work.  Were they not running before,
>>>> or did something else change?
>>>
>>> AFAIU the commit, the tests were not run on x86_64-*-*, so the tests and the corresponding failures are new.
>>
>> Well, the commit fixed the fact that they weren't running on x86_64 for the
>> -m32 multilib.  If you had built a i686-darwin before the commit, the tests
>> should have already been running (and, presumably, failing).
> 
> I don't think (To Be Confirmed) this mode has ever been tested on Darwin in previous incarnations of libffi.
> (i.e darwin + windows call markers)  ISTM that the first occassion was following your commit 12th Jan.

Oh, duh.  I must have been asleep yesterday evening or something.

Of course these tests won't work on darwin.  At least not until
it can actually use the modern x86/ffi.c instead of the old code
that got copied in to x86/darwin_c.c

> Well, somewhat confusingly "x86/darwin_c.c" is shared between darwin and the various Windows 32 bit implementations.

It's not shared with anything.  It's a copy of the old x86/ffi.c
prior to the merge from upstream.


r~

Re: [COMMITTED] Merge libffi with upstream

[Dominique d'Humières]

I have filed pr64855.

Dominique

> Le 29 janv. 2015 à 10:10, Iain Sandoe <iain@codesourcery.com> a écrit :
> 
> 
> On 28 Jan 2015, at 18:16, Richard Henderson wrote:
> 
>> On 01/28/2015 10:10 AM, Dominique d'Humières wrote:
>>>> I can't think of any reason they shouldn't work.  Were they not running before,
>>>> or did something else change?
>>> 
>>> AFAIU the commit, the tests were not run on x86_64-*-*, so the tests and the corresponding failures are new.
>> 
>> Well, the commit fixed the fact that they weren't running on x86_64 for the
>> -m32 multilib.  If you had built a i686-darwin before the commit, the tests
>> should have already been running (and, presumably, failing).
> 
> I don't think (To Be Confirmed) this mode has ever been tested on Darwin in previous incarnations of libffi.
> (i.e darwin + windows call markers)  ISTM that the first occassion was following your commit 12th Jan.
> 
> 
>>> If you think the failures are a bug, I’ll open a PR for them.
>> 
>> I do think the failures are a bug.  If Darwin wasn't supposed to support these
>> abis, they ought to have failed test compilation, not test execution.
> 
> 
> Well, somewhat confusingly "x86/darwin_c.c" is shared between darwin and the various Windows 32 bit implementations.  It might be nice to rename it (but that can wait ...).
> 
> A quick look suggests that FFI_THISCALL and friends will result in an abort or a return of "invalid ABI" on Darwin, but I don't (yet) see a compile-time error.  We need to look into adding that - and disabling any inappropriate tests on Darwin.
> 
> Iain

Re: [COMMITTED] Merge libffi with upstream

[Iain Sandoe]

On 28 Jan 2015, at 18:16, Richard Henderson wrote:

> On 01/28/2015 10:10 AM, Dominique d'Humières wrote:
>>> I can't think of any reason they shouldn't work.  Were they not running before,
>>> or did something else change?
>> 
>> AFAIU the commit, the tests were not run on x86_64-*-*, so the tests and the corresponding failures are new.
> 
> Well, the commit fixed the fact that they weren't running on x86_64 for the
> -m32 multilib.  If you had built a i686-darwin before the commit, the tests
> should have already been running (and, presumably, failing).

I don't think (To Be Confirmed) this mode has ever been tested on Darwin in previous incarnations of libffi.
(i.e darwin + windows call markers)  ISTM that the first occassion was following your commit 12th Jan.


>> If you think the failures are a bug, I’ll open a PR for them.
> 
> I do think the failures are a bug.  If Darwin wasn't supposed to support these
> abis, they ought to have failed test compilation, not test execution.


Well, somewhat confusingly "x86/darwin_c.c" is shared between darwin and the various Windows 32 bit implementations.  It might be nice to rename it (but that can wait ...).

A quick look suggests that FFI_THISCALL and friends will result in an abort or a return of "invalid ABI" on Darwin, but I don't (yet) see a compile-time error.  We need to look into adding that - and disabling any inappropriate tests on Darwin.

Iain

Re: [COMMITTED] Merge libffi with upstream

[Richard Henderson]

On 01/28/2015 10:10 AM, Dominique d'Humières wrote:
>> I can't think of any reason they shouldn't work.  Were they not running before,
>> or did something else change?
> 
> AFAIU the commit, the tests were not run on x86_64-*-*, so the tests and the corresponding failures are new.

Well, the commit fixed the fact that they weren't running on x86_64 for the
-m32 multilib.  If you had built a i686-darwin before the commit, the tests
should have already been running (and, presumably, failing).

> If you think the failures are a bug, IÂ’ll open a PR for them.

I do think the failures are a bug.  If Darwin wasn't supposed to support these
abis, they ought to have failed test compilation, not test execution.


r~

Re: [COMMITTED] Merge libffi with upstream

[Dominique d'Humières]

> Le 28 janv. 2015 à 19:03, Richard Henderson <rth@redhat.com> a écrit :
> 
> On 01/28/2015 06:28 AM, Dominique Dhumieres wrote:
>>> This patch worked for me.  Ok for mainline now? (r220158)
>> 
>> This causes 340 new tests on darwin with -m32, 255 of them failing when executes,
>> see https://gcc.gnu.org/ml/gcc-testresults/2015-01/msg03197.html.
>> 
>> Are the tests with '-DABI_NUM=*' supposed to work on darwin?
> 
> I can't think of any reason they shouldn't work.  Were they not running before,
> or did something else change?

AFAIU the commit, the tests were not run on x86_64-*-*, so the tests and the corresponding failures are new.

If you think the failures are a bug, I’ll open a PR for them.

Dominique

> r~

Re: [COMMITTED] Merge libffi with upstream

[Richard Henderson]

On 01/28/2015 06:28 AM, Dominique Dhumieres wrote:
>> This patch worked for me.  Ok for mainline now? (r220158)
> 
> This causes 340 new tests on darwin with -m32, 255 of them failing when executes,
> see https://gcc.gnu.org/ml/gcc-testresults/2015-01/msg03197.html.
> 
> Are the tests with '-DABI_NUM=*' supposed to work on darwin?

I can't think of any reason they shouldn't work.  Were they not running before,
or did something else change?


r~

Re: [COMMITTED] Merge libffi with upstream

[Dominique Dhumieres]

> This patch worked for me.  Ok for mainline now? (r220158)

This causes 340 new tests on darwin with -m32, 255 of them failing when executes,
see https://gcc.gnu.org/ml/gcc-testresults/2015-01/msg03197.html.

Are the tests with '-DABI_NUM=*' supposed to work on darwin?

If yes, I'll open a PR; if no, could they be disabled for darwin.

TIA

Dominique

Re: [COMMITTED] Merge libffi with upstream

[Gerald Pfeifer]

Bootstrap on FreeBSD 10.x/i386 is now broken:

libtool: compile:  /scratch2/tmp/gerald/OBJ-0124-0939/./gcc/xgcc -B/scratch2/tmp/gerald/OBJ-0124-0939/./gcc/ -B/home/gerald/gcc-ref10-i386/i386-unknown-freebsd10.1/bin/ -B/home/gerald/gcc-ref10-i386/i386-unknown-freebsd10.1/lib/ -isystem /home/gerald/gcc-ref10-i386/i386-unknown-freebsd10.1/include -isystem /home/gerald/gcc-ref10-i386/i386-unknown-freebsd10.1/sys-include -DHAVE_CONFIG_H -I. -I/scratch2/tmp/gerald/gcc-HEAD/libffi -I. -I/scratch2/tmp/gerald/gcc-HEAD/libffi/include -Iinclude -I/scratch2/tmp/gerald/gcc-HEAD/libffi/src -I. -I/scratch2/tmp/gerald/gcc-HEAD/libffi/include -Iinclude -I/scratch2/tmp/gerald/gcc-HEAD/libffi/src -g -O2 -MT src/x86/sysv.lo -MD -MP -MF src/x86/.deps/sysv.Tpo -c /scratch2/tmp/gerald/gcc-HEAD/libffi/src/x86/sysv.S  -fPIC -DPIC -o src/x86/.libs/sysv.o
/scratch2/tmp/gerald/gcc-HEAD/libffi/src/x86/sysv.S: Assembler messages:
/scratch2/tmp/gerald/gcc-HEAD/libffi/src/x86/sysv.S:864: Error: junk at end of line, first unrecognized character is `@'
/scratch2/tmp/gerald/gcc-HEAD/libffi/src/x86/sysv.S:886: Error: junk at end of line, first unrecognized character is `@'
/scratch2/tmp/gerald/gcc-HEAD/libffi/src/x86/sysv.S:898: Error: junk at end of line, first unrecognized character is `@'
/scratch2/tmp/gerald/gcc-HEAD/libffi/src/x86/sysv.S:910: Error: junk at end of line, first unrecognized character is `@'
/scratch2/tmp/gerald/gcc-HEAD/libffi/src/x86/sysv.S:938: Error: junk at end of line, first unrecognized character is `@'
/scratch2/tmp/gerald/gcc-HEAD/libffi/src/x86/sysv.S:950: Error: junk at end of line, first unrecognized character is `@'
/scratch2/tmp/gerald/gcc-HEAD/libffi/src/x86/sysv.S:964: Error: junk at end of line, first unrecognized character is `@'
/scratch2/tmp/gerald/gcc-HEAD/libffi/src/x86/sysv.S:983: Error: junk at end of line, first unrecognized character is `@'
/scratch2/tmp/gerald/gcc-HEAD/libffi/src/x86/sysv.S:1007: Error: junk at end ofline, first unrecognized character is `@'
Makefile:1177: recipe for target 'src/x86/sysv.lo' failed
gmake[4]: *** [src/x86/sysv.lo] Error 1
gmake[4]: Leaving directory 
'/scratch2/tmp/gerald/OBJ-0124-0939/i386-unknown-fre
ebsd10.1/libffi'
Makefile:1433: recipe for target 'all-recursive' failed
gmake[3]: *** [all-recursive] Error 1

I also filed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64779 so
that this can be tracked for the GCC 5.0 release.

Gerald

Re: [COMMITTED] Merge libffi with upstream

[Richard Henderson]

On 01/12/2015 11:08 AM, Uros Bizjak wrote:
> Hello!
> 
>> Upstream libffi has added support for Go closures (using the static chain),
>> and support for complex numbers.  Perhaps less relevant is new support for
>> arc, microblaze, moxie, nios, and or1k targets.
>>
>> Without additional changes for Go, this merge has little effect.  Within the
>> gcc tree libffi is primarily used by libjava.
>>
>> Tested with no regressions on {i686,x86_64,ppc64,s390x,aarch64,alpha}-linux.
> 
> This patchset regressed libjava on -m32 x86_64-linux-gnu (Fedora 21):
> 
>         === libjava tests ===
> 
> 
> Running target unix
> 
>         === libjava Summary for unix ===
> 
> 
> Running target unix/-m32
> FAIL: libjava.jar/TestClosureGC.jar execution - gij test
> FAIL: libjava.jar/simple.jar execution - gij test
...


Ug.  I don't know how I let this slip by.  Fixed thus.


r~


        * src/x86/ffi.c (ffi_raw_call): Fill in frame.


diff --git a/libffi/src/x86/ffi.c b/libffi/src/x86/ffi.c
index 3885e39..feb5cbb 100644
--- a/libffi/src/x86/ffi.c
+++ b/libffi/src/x86/ffi.c
@@ -675,6 +675,10 @@ ffi_raw_call
   if (rsize)
     rvalue = frame + 1;

+  frame->fn = fn;
+  frame->flags = flags;
+  frame->rvalue = rvalue;
+
   narg_reg = 0;
   switch (flags)
     {

Re: [COMMITTED] Merge libffi with upstream

[H.J. Lu]

On Mon, Jan 12, 2015 at 2:31 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Mon, Jan 12, 2015 at 11:08 AM, Uros Bizjak <ubizjak@gmail.com> wrote:
>> Hello!
>>
>>> Upstream libffi has added support for Go closures (using the static chain),
>>> and support for complex numbers.  Perhaps less relevant is new support for
>>> arc, microblaze, moxie, nios, and or1k targets.
>>>
>>> Without additional changes for Go, this merge has little effect.  Within the
>>> gcc tree libffi is primarily used by libjava.
>>>
>>> Tested with no regressions on {i686,x86_64,ppc64,s390x,aarch64,alpha}-linux.
>>
>> This patchset regressed libjava on -m32 x86_64-linux-gnu (Fedora 21):
>>
>>         === libjava tests ===
>>
>>
>> Running target unix
>>
>>         === libjava Summary for unix ===
>>
>>
>> Running target unix/-m32
>> FAIL: libjava.jar/TestClosureGC.jar execution - gij test
>> FAIL: libjava.jar/simple.jar execution - gij test
>> FAIL: PR15133 execution - gij test
>> FAIL: PR18116 execution - gij test
>> FAIL: PR28178 execution - gij test
>> FAIL: bytebuffer execution - gij test
>> FAIL: calls execution - gij test
>> FAIL: cxxtest execution - gij test
>> FAIL: directbuffer execution - gij test
>> FAIL: field execution - gij test
>> FAIL: final_method execution - gij test
>> FAIL: findclass execution - gij test
>> FAIL: findclass2 execution - gij test
>> FAIL: iface execution - gij test
>> FAIL: init execution - gij test
>> FAIL: invoke execution - gij test
>> FAIL: jniutf execution - gij test
>> FAIL: martin execution - gij test
>> FAIL: noclass execution - gij test
>> FAIL: overload execution - gij test
>> FAIL: pr11951 execution - gij test
>> FAIL: pr18278 execution - gij test
>> FAIL: pr23739 execution - gij test
>> FAIL: register execution - gij test
>> FAIL: register2 execution - gij test
>> FAIL: simple_int execution - gij test
>> FAIL: throwit execution - gij test
>> FAIL: virtual execution - gij test
>> FAIL: PR16923 run
>> FAIL: pr29812 execution - gij test
>> FAIL: getargssize run
>> FAIL: getlocalvartable run
>> FAIL: getstacktrace run
>> FAIL: ExtraClassLoader execution - source compiled test
>> FAIL: ExtraClassLoader -findirect-dispatch execution - source compiled test
>> FAIL: ExtraClassLoader -O3 execution - source compiled test
>> FAIL: ExtraClassLoader -O3 -findirect-dispatch execution - source compiled test
>> FAIL: TestEarlyGC execution - source compiled test
>>
>>         === libjava Summary for unix/-m32 ===
>>
>>
>>         === libjava Summary ===
>>
>> # of expected passes        5092
>> # of unexpected failures    38
>> # of expected failures        8
>> # of untested testcases        38
>
> It also breaks x32:
>
> https://gcc.gnu.org/ml/gcc-regression/2015-01/msg00203.html
>
> libtool: link: /export/gnu/import/git/gcc-test-x32/bld/./gcc/xgcc
> -shared-libgcc -B/export/gnu/import/git/gcc-test-x32/bld/./gcc
> -nostdinc++ -L/export/gnu/import/git/gcc-test-x32/bld/x86_64-unknown-linux-gnu/x32/libstdc++-v3/src
> -L/export/gnu/import/git/gcc-test-x32/bld/x86_64-unknown-linux-gnu/x32/libstdc++-v3/src/.libs
> -L/export/gnu/import/git/gcc-test-x32/bld/x86_64-unknown-linux-gnu/x32/libstdc++-v3/libsupc++/.libs
> -B/usr/5.0.0/x86_64-unknown-linux-gnu/bin/
> -B/usr/5.0.0/x86_64-unknown-linux-gnu/lib/ -isystem
> /usr/5.0.0/x86_64-unknown-linux-gnu/include -isystem
> /usr/5.0.0/x86_64-unknown-linux-gnu/sys-include  -mx32  -fPIC -DPIC
> -shared -nostdlib /lib/../libx32/crti.o
> /export/gnu/import/git/gcc-test-x32/bld/./gcc/x32/crtbeginS.o
> .libs/jni-libjvm.o   -Wl,-rpath
> -Wl,/export/gnu/import/git/gcc-test-x32/bld/x86_64-unknown-linux-gnu/x32/libjava/.libs
> -Wl,-rpath -Wl,/usr/5.0.0/lib/../libx32
> -L/export/gnu/import/git/gcc-test-x32/bld/x86_64-unknown-linux-gnu/x32/libjava/.libs
> -L/export/gnu/import/git/gcc-test-x32/bld/x86_64-unknown-linux-gnu/x32/libstdc++-v3/src
> -L/export/gnu/import/git/gcc-test-x32/bld/x86_64-unknown-linux-gnu/x32/libstdc++-v3/src/.libs
> -L/export/gnu/import/git/gcc-test-x32/bld/x86_64-unknown-linux-gnu/x32/libstdc++-v3/libsupc++/.libs
> ./.libs/libgcj.so
> -L/export/gnu/import/git/gcc-test-x32/bld/x86_64-unknown-linux-gnu/x32/libjava
> -lpthread -lrt -ldl -lz
> -L/export/gnu/import/git/gcc-test-x32/bld/./gcc/x32 -L/lib/../libx32
> -L/usr/lib/../libx32 -L/export/gnu/import/git/gcc-test-x32/bld/./gcc
> -lc -lgcc_s /export/gnu/import/git/gcc-test-x32/bld/./gcc/x32/crtendS.o
> /lib/../libx32/crtn.o  -mx32 -mx32 -mx32 -Wl,-Bsymbolic   -Wl,-soname
> -Wl,libjvm.so -o .libs/libjvm.so
> ./.libs/libgcj.so: undefined reference to `ffi_raw_call'
> ./.libs/libgcj.so: undefined reference to `ffi_prep_raw_closure_loc'
> ./.libs/libgcj.so: undefined reference to `ffi_prep_cif_machdep'
> ./.libs/libgcj.so: undefined reference to `ffi_prep_closure_loc'
> ./.libs/libgcj.so: undefined reference to `ffi_call'
> collect2: error: ld returned 1 exit status
> make[8]: *** [jv-convert] Error 1
>
> --
> H.J.

I opened:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64575

-- 
H.J.

Re: [COMMITTED] Merge libffi with upstream

[Dominique Dhumieres]

> ... Due to upstream breakage, and difficulty debugging on Darwin,
> {i686,x86_64}-darwin retains copies of the existing sources and thus remains
> 100% unchanged. ...

Nevertheless the commit breaks bootstrap on darwin:

...
libtool: link: /opt/gcc/build_w/./gcc/xgcc -B/opt/gcc/build_w/./gcc/ -B/opt/gcc/gcc4.10w/x86_64-apple-darwin14.0.0/bin/ -B/opt/gcc/gcc4.10w/x86_64-apple-darwin14.0.0/lib/ -isystem /opt/gcc/gcc4.10w/x86_64-apple-darwin14.0.0/include -isystem /opt/gcc/gcc4.10w/x86_64-apple-darwin14.0.0/sys-include    -dynamiclib  -o .libs/libffi.4.dylib  src/.libs/prep_cif.o src/.libs/types.o src/.libs/raw_api.o src/.libs/java_raw_api.o src/.libs/closures.o src/x86/.libs/darwin64_c.o src/x86/.libs/darwin64.o      -install_name  /opt/gcc/gcc4.10w/lib/libffi.4.dylib -compatibility_version 5 -current_version 5.1 -Wl,-single_module
Undefined symbols for architecture x86_64:
  "_ffi_prep_raw_closure_loc", referenced from:
      _ffi_prep_raw_closure in raw_api.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status
...

Dominique

Re: [COMMITTED] Merge libffi with upstream

[H.J. Lu]

On Mon, Jan 12, 2015 at 11:08 AM, Uros Bizjak <ubizjak@gmail.com> wrote:
> Hello!
>
>> Upstream libffi has added support for Go closures (using the static chain),
>> and support for complex numbers.  Perhaps less relevant is new support for
>> arc, microblaze, moxie, nios, and or1k targets.
>>
>> Without additional changes for Go, this merge has little effect.  Within the
>> gcc tree libffi is primarily used by libjava.
>>
>> Tested with no regressions on {i686,x86_64,ppc64,s390x,aarch64,alpha}-linux.
>
> This patchset regressed libjava on -m32 x86_64-linux-gnu (Fedora 21):
>
>         === libjava tests ===
>
>
> Running target unix
>
>         === libjava Summary for unix ===
>
>
> Running target unix/-m32
> FAIL: libjava.jar/TestClosureGC.jar execution - gij test
> FAIL: libjava.jar/simple.jar execution - gij test
> FAIL: PR15133 execution - gij test
> FAIL: PR18116 execution - gij test
> FAIL: PR28178 execution - gij test
> FAIL: bytebuffer execution - gij test
> FAIL: calls execution - gij test
> FAIL: cxxtest execution - gij test
> FAIL: directbuffer execution - gij test
> FAIL: field execution - gij test
> FAIL: final_method execution - gij test
> FAIL: findclass execution - gij test
> FAIL: findclass2 execution - gij test
> FAIL: iface execution - gij test
> FAIL: init execution - gij test
> FAIL: invoke execution - gij test
> FAIL: jniutf execution - gij test
> FAIL: martin execution - gij test
> FAIL: noclass execution - gij test
> FAIL: overload execution - gij test
> FAIL: pr11951 execution - gij test
> FAIL: pr18278 execution - gij test
> FAIL: pr23739 execution - gij test
> FAIL: register execution - gij test
> FAIL: register2 execution - gij test
> FAIL: simple_int execution - gij test
> FAIL: throwit execution - gij test
> FAIL: virtual execution - gij test
> FAIL: PR16923 run
> FAIL: pr29812 execution - gij test
> FAIL: getargssize run
> FAIL: getlocalvartable run
> FAIL: getstacktrace run
> FAIL: ExtraClassLoader execution - source compiled test
> FAIL: ExtraClassLoader -findirect-dispatch execution - source compiled test
> FAIL: ExtraClassLoader -O3 execution - source compiled test
> FAIL: ExtraClassLoader -O3 -findirect-dispatch execution - source compiled test
> FAIL: TestEarlyGC execution - source compiled test
>
>         === libjava Summary for unix/-m32 ===
>
>
>         === libjava Summary ===
>
> # of expected passes        5092
> # of unexpected failures    38
> # of expected failures        8
> # of untested testcases        38

It also breaks x32:

https://gcc.gnu.org/ml/gcc-regression/2015-01/msg00203.html

libtool: link: /export/gnu/import/git/gcc-test-x32/bld/./gcc/xgcc
-shared-libgcc -B/export/gnu/import/git/gcc-test-x32/bld/./gcc
-nostdinc++ -L/export/gnu/import/git/gcc-test-x32/bld/x86_64-unknown-linux-gnu/x32/libstdc++-v3/src
-L/export/gnu/import/git/gcc-test-x32/bld/x86_64-unknown-linux-gnu/x32/libstdc++-v3/src/.libs
-L/export/gnu/import/git/gcc-test-x32/bld/x86_64-unknown-linux-gnu/x32/libstdc++-v3/libsupc++/.libs
-B/usr/5.0.0/x86_64-unknown-linux-gnu/bin/
-B/usr/5.0.0/x86_64-unknown-linux-gnu/lib/ -isystem
/usr/5.0.0/x86_64-unknown-linux-gnu/include -isystem
/usr/5.0.0/x86_64-unknown-linux-gnu/sys-include  -mx32  -fPIC -DPIC
-shared -nostdlib /lib/../libx32/crti.o
/export/gnu/import/git/gcc-test-x32/bld/./gcc/x32/crtbeginS.o
.libs/jni-libjvm.o   -Wl,-rpath
-Wl,/export/gnu/import/git/gcc-test-x32/bld/x86_64-unknown-linux-gnu/x32/libjava/.libs
-Wl,-rpath -Wl,/usr/5.0.0/lib/../libx32
-L/export/gnu/import/git/gcc-test-x32/bld/x86_64-unknown-linux-gnu/x32/libjava/.libs
-L/export/gnu/import/git/gcc-test-x32/bld/x86_64-unknown-linux-gnu/x32/libstdc++-v3/src
-L/export/gnu/import/git/gcc-test-x32/bld/x86_64-unknown-linux-gnu/x32/libstdc++-v3/src/.libs
-L/export/gnu/import/git/gcc-test-x32/bld/x86_64-unknown-linux-gnu/x32/libstdc++-v3/libsupc++/.libs
./.libs/libgcj.so
-L/export/gnu/import/git/gcc-test-x32/bld/x86_64-unknown-linux-gnu/x32/libjava
-lpthread -lrt -ldl -lz
-L/export/gnu/import/git/gcc-test-x32/bld/./gcc/x32 -L/lib/../libx32
-L/usr/lib/../libx32 -L/export/gnu/import/git/gcc-test-x32/bld/./gcc
-lc -lgcc_s /export/gnu/import/git/gcc-test-x32/bld/./gcc/x32/crtendS.o
/lib/../libx32/crtn.o  -mx32 -mx32 -mx32 -Wl,-Bsymbolic   -Wl,-soname
-Wl,libjvm.so -o .libs/libjvm.so
./.libs/libgcj.so: undefined reference to `ffi_raw_call'
./.libs/libgcj.so: undefined reference to `ffi_prep_raw_closure_loc'
./.libs/libgcj.so: undefined reference to `ffi_prep_cif_machdep'
./.libs/libgcj.so: undefined reference to `ffi_prep_closure_loc'
./.libs/libgcj.so: undefined reference to `ffi_call'
collect2: error: ld returned 1 exit status
make[8]: *** [jv-convert] Error 1

-- 
H.J.

Re: [COMMITTED] Merge libffi with upstream

[Uros Bizjak]

Hello!

> Upstream libffi has added support for Go closures (using the static chain),
> and support for complex numbers.  Perhaps less relevant is new support for
> arc, microblaze, moxie, nios, and or1k targets.
>
> Without additional changes for Go, this merge has little effect.  Within the
> gcc tree libffi is primarily used by libjava.
>
> Tested with no regressions on {i686,x86_64,ppc64,s390x,aarch64,alpha}-linux.

This patchset regressed libjava on -m32 x86_64-linux-gnu (Fedora 21):

        === libjava tests ===


Running target unix

        === libjava Summary for unix ===


Running target unix/-m32
FAIL: libjava.jar/TestClosureGC.jar execution - gij test
FAIL: libjava.jar/simple.jar execution - gij test
FAIL: PR15133 execution - gij test
FAIL: PR18116 execution - gij test
FAIL: PR28178 execution - gij test
FAIL: bytebuffer execution - gij test
FAIL: calls execution - gij test
FAIL: cxxtest execution - gij test
FAIL: directbuffer execution - gij test
FAIL: field execution - gij test
FAIL: final_method execution - gij test
FAIL: findclass execution - gij test
FAIL: findclass2 execution - gij test
FAIL: iface execution - gij test
FAIL: init execution - gij test
FAIL: invoke execution - gij test
FAIL: jniutf execution - gij test
FAIL: martin execution - gij test
FAIL: noclass execution - gij test
FAIL: overload execution - gij test
FAIL: pr11951 execution - gij test
FAIL: pr18278 execution - gij test
FAIL: pr23739 execution - gij test
FAIL: register execution - gij test
FAIL: register2 execution - gij test
FAIL: simple_int execution - gij test
FAIL: throwit execution - gij test
FAIL: virtual execution - gij test
FAIL: PR16923 run
FAIL: pr29812 execution - gij test
FAIL: getargssize run
FAIL: getlocalvartable run
FAIL: getstacktrace run
FAIL: ExtraClassLoader execution - source compiled test
FAIL: ExtraClassLoader -findirect-dispatch execution - source compiled test
FAIL: ExtraClassLoader -O3 execution - source compiled test
FAIL: ExtraClassLoader -O3 -findirect-dispatch execution - source compiled test
FAIL: TestEarlyGC execution - source compiled test

        === libjava Summary for unix/-m32 ===


        === libjava Summary ===

# of expected passes        5092
# of unexpected failures    38
# of expected failures        8
# of untested testcases        38

Uros.