[libitm] Work around missing AVX support

[libitm] Work around missing AVX support

[Richard Henderson]

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

Not pretty at all.  But given the corresponding irritation in writing assembler
wrapper functions, it seems like it's about a wash.

Tested with and without HAVE_AS_AVX on x86_64-linux.


r~

[-- Attachment #2: z --]
[-- Type: text/plain, Size: 4285 bytes --]

commit 856dd9f4777fbafce3038e889e9a9bf48222215d
Author: Richard Henderson <rth@redhat.com>
Date:   Wed Nov 9 16:28:45 2011 -0800

    libitm: Work around assembler missing AVX insns.

diff --git a/libitm/ChangeLog b/libitm/ChangeLog
index b1629b1..8aeb589 100644
--- a/libitm/ChangeLog
+++ b/libitm/ChangeLog
@@ -1,5 +1,12 @@
 2011-11-09  Richard Henderson  <rth@redhat.com>
 
+	* acinclude.m4 (LIBITM_CHECK_AS_AVX): New.
+	* configure.ac: Use it.
+	* config.h.in, configure: Rebuild.
+	* config/x86/x86_avx.cc: Handle !HAVE_AS_AVX.
+
+2011-11-09  Richard Henderson  <rth@redhat.com>
+
 	* barrier.tpl, memcpy.cc, memset.cc, method-wbetl.cc: Remove file.
 	* config/alpha/unaligned.h: Remove file.
 	* config/generic/unaligned.h: Remove file.
diff --git a/libitm/acinclude.m4 b/libitm/acinclude.m4
index 8fcde4b..58fbf42 100644
--- a/libitm/acinclude.m4
+++ b/libitm/acinclude.m4
@@ -95,6 +95,20 @@ AC_DEFUN([LIBITM_CHECK_SIZE_T_MANGLING], [
     [Define to the letter to which size_t is mangled.])
 ])
 
+dnl Check if as supports AVX instructions.
+AC_DEFUN([LIBITM_CHECK_AS_AVX], [
+case "${target_cpu}" in
+i[3456]86 | x86_64)
+  AC_CACHE_CHECK([if the assembler supports AVX], libitm_cv_as_avx, [
+    AC_TRY_COMPILE([], [asm("vzeroupper");],
+		   [libitm_cv_as_avx=yes], [libitm_cv_as_avx=no])
+  ])
+  if test x$libitm_cv_as_avx = xyes; then
+    AC_DEFINE(HAVE_AS_AVX, 1, [Define to 1 if the assembler supports AVX.])
+  fi
+  ;;
+esac])
+
 sinclude(../libtool.m4)
 dnl The lines below arrange for aclocal not to bring an installed
 dnl libtool.m4 into aclocal.m4, while still arranging for automake to
diff --git a/libitm/config/x86/x86_avx.cc b/libitm/config/x86/x86_avx.cc
index 30420aa..cd20fe2 100644
--- a/libitm/config/x86/x86_avx.cc
+++ b/libitm/config/x86/x86_avx.cc
@@ -22,9 +22,66 @@
    see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
    <http://www.gnu.org/licenses/>.  */
 
+#include "config.h"
+
+// ??? This is pretty gross, but we're going to frob types of the functions.
+// Is this better or worse than just admitting we need to do this in pure
+// assembly?
+
+#ifndef HAVE_AS_AVX
+#undef __AVX__
+#endif
+
 #include "libitm_i.h"
 #include "dispatch.h"
 
+extern "C" {
+
+#ifndef HAVE_AS_AVX
+typedef float _ITM_TYPE_M256 __attribute__((vector_size(32), may_alias));
+#endif
+
+// ??? Re-define the memcpy implementations so that we can frob the
+// interface to deal with possibly missing AVX instruction set support.
+
+#ifdef HAVE_AS_AVX
+#define RETURN(X)	return X
+#define STORE(X,Y)	X = Y
+#define OUTPUT(T)	_ITM_TYPE_##T
+#define INPUT(T,X)	, _ITM_TYPE_##T X
+#else
+/* Emit vmovaps (%rax),%ymm0.  */
+#define RETURN(X) \
+  asm volatile(".byte 0xc5,0xfc,0x28,0x00" : "=m"(X) : "a"(&X));
+/* Emit vmovaps %ymm0,(%rax); vzeroupper.  */
+#define STORE(X,Y) \
+  asm volatile(".byte 0xc5,0xfc,0x29,0x00,0xc5,0xf8,0x77" : "=m"(X) : "a"(&X));
+#define OUTPUT(T)	void
+#define INPUT(T,X)
+#endif
+
+#undef ITM_READ_MEMCPY
+#define ITM_READ_MEMCPY(T, LSMOD, TARGET, M2)				\
+OUTPUT(T) ITM_REGPARM _ITM_##LSMOD##T (const _ITM_TYPE_##T *ptr)	\
+{									\
+  _ITM_TYPE_##T v;							\
+  TARGET memtransfer##M2(&v, ptr, sizeof(_ITM_TYPE_##T), false,		\
+			 GTM::abi_dispatch::NONTXNAL,			\
+			 GTM::abi_dispatch::LSMOD);			\
+  RETURN(v);								\
+}
+
+#undef ITM_WRITE_MEMCPY
+#define ITM_WRITE_MEMCPY(T, LSMOD, TARGET, M2)				\
+void ITM_REGPARM _ITM_##LSMOD##T (_ITM_TYPE_##T *ptr INPUT(T,in))	\
+{									\
+  _ITM_TYPE_##T v;							\
+  STORE(v, in);								\
+  TARGET memtransfer##M2(ptr, &v, sizeof(_ITM_TYPE_##T), false,		\
+			 GTM::abi_dispatch::LSMOD,			\
+			 GTM::abi_dispatch::NONTXNAL);			\
+}
+
 // ??? Use memcpy for now, until we have figured out how to best instantiate
 // these loads/stores.
 CREATE_DISPATCH_FUNCTIONS_T_MEMCPY(M256, GTM::abi_disp()->, )
@@ -34,3 +91,5 @@ _ITM_LM256 (const _ITM_TYPE_M256 *ptr)
 {
   GTM::GTM_LB (ptr, sizeof (*ptr));
 }
+
+}
diff --git a/libitm/configure.ac b/libitm/configure.ac
index c40ecb5..7de5cbe 100644
--- a/libitm/configure.ac
+++ b/libitm/configure.ac
@@ -237,6 +237,7 @@ CFLAGS="$save_CFLAGS $XCFLAGS"
 # had a chance to set XCFLAGS.
 LIBITM_CHECK_SYNC_BUILTINS
 LIBITM_CHECK_64BIT_SYNC_BUILTINS
+LIBITM_CHECK_AS_AVX
 
 # Cleanup and exit.
 CFLAGS="$save_CFLAGS"

Re: [libitm] Work around missing AVX support

[Jakub Jelinek]

On Wed, Nov 09, 2011 at 04:32:58PM -0800, Richard Henderson wrote:
> Not pretty at all.  But given the corresponding irritation in writing assembler
> wrapper functions, it seems like it's about a wash.
> 
> Tested with and without HAVE_AS_AVX on x86_64-linux.

Shouldn't -mavx be also not passed in that case?  Then you wouldn't need
to undef __AVX__ and we wouldn't risk gcc doesn't decide to optimize memcpy
or something similar using AVX instructions...

	Jakub

Re: [libitm] Work around missing AVX support

[Richard Henderson]

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

On 11/10/2011 12:16 AM, Jakub Jelinek wrote:
> On Wed, Nov 09, 2011 at 04:32:58PM -0800, Richard Henderson wrote:
>> Not pretty at all.  But given the corresponding irritation in writing assembler
>> wrapper functions, it seems like it's about a wash.
>>
>> Tested with and without HAVE_AS_AVX on x86_64-linux.
> Shouldn't -mavx be also not passed in that case?  Then you wouldn't need
> to undef __AVX__ and we wouldn't risk gcc doesn't decide to optimize memcpy
> or something similar using AVX instructions...
>
You are correct.  Thanks for noticing this; I was a bit frazzled after fighting with autofoo for so long yesterday.

Tested on x86_64-linux, with avx and with avx forcibly disabled.


r~

[-- Attachment #2: z --]
[-- Type: text/plain, Size: 5802 bytes --]

commit b8190fde2cd04078f8448576fb021060526b51d5
Author: rth <rth@138bc75d-0d04-0410-961f-82ee72b054a4>
Date:   Thu Nov 10 17:09:04 2011 +0000

    libitm: Don't add -mavx if the assembler doesn't support avx.
    
            * config/x86/x86_avx.cc: Remove #undef __AVX__ hack.  Tidy comments.
            * Makefile.am (x86_avx.lo): Only add -mavx if ARCH_X86_AVX.
            * configure.ac (ARCH_X86_AVX): New conditional.
            * Makefile.in, configure: Rebuild.
    
    git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@181261 138bc75d-0d04-0410-961f-82ee72b054a4

diff --git a/libitm/ChangeLog b/libitm/ChangeLog
index 8aeb589..4fb699e 100644
--- a/libitm/ChangeLog
+++ b/libitm/ChangeLog
@@ -1,3 +1,10 @@
+2011-11-10  Richard Henderson  <rth@redhat.com>
+
+	* config/x86/x86_avx.cc: Remove #undef __AVX__ hack.  Tidy comments.
+	* Makefile.am (x86_avx.lo): Only add -mavx if ARCH_X86_AVX.
+	* configure.ac (ARCH_X86_AVX): New conditional.
+	* Makefile.in, configure: Rebuild.
+
 2011-11-09  Richard Henderson  <rth@redhat.com>
 
 	* acinclude.m4 (LIBITM_CHECK_AS_AVX): New.
diff --git a/libitm/Makefile.am b/libitm/Makefile.am
index 4578986..b4674a5 100644
--- a/libitm/Makefile.am
+++ b/libitm/Makefile.am
@@ -48,6 +48,8 @@ libitm_la_SOURCES = \
 if ARCH_X86
 libitm_la_SOURCES += x86_sse.cc x86_avx.cc
 x86_sse.lo : XCFLAGS += -msse
+endif
+if ARCH_X86_AVX
 x86_avx.lo : XCFLAGS += -mavx
 endif
 
diff --git a/libitm/Makefile.in b/libitm/Makefile.in
index 8816580..7426146 100644
--- a/libitm/Makefile.in
+++ b/libitm/Makefile.in
@@ -1259,7 +1259,7 @@ uninstall-am: uninstall-dvi-am uninstall-html-am uninstall-info-am \
 
 vpath % $(strip $(search_path))
 @ARCH_X86_TRUE@x86_sse.lo : XCFLAGS += -msse
-@ARCH_X86_TRUE@x86_avx.lo : XCFLAGS += -mavx
+@ARCH_X86_AVX_TRUE@x86_avx.lo : XCFLAGS += -mavx
 
 all-local: $(STAMP_GENINSRC)
 
diff --git a/libitm/config/x86/x86_avx.cc b/libitm/config/x86/x86_avx.cc
index cd20fe2..6a5e297 100644
--- a/libitm/config/x86/x86_avx.cc
+++ b/libitm/config/x86/x86_avx.cc
@@ -24,24 +24,20 @@
 
 #include "config.h"
 
-// ??? This is pretty gross, but we're going to frob types of the functions.
-// Is this better or worse than just admitting we need to do this in pure
-// assembly?
-
-#ifndef HAVE_AS_AVX
-#undef __AVX__
-#endif
-
 #include "libitm_i.h"
 #include "dispatch.h"
 
 extern "C" {
 
 #ifndef HAVE_AS_AVX
+// If we don't have an AVX capable assembler, we didn't set -mavx on the
+// command-line either, which means that libitm.h defined neither this type
+// nor the functions in this file.  Define the type and unconditionally
+// wrap the file in extern "C" to make up for the lack of pre-declaration.
 typedef float _ITM_TYPE_M256 __attribute__((vector_size(32), may_alias));
 #endif
 
-// ??? Re-define the memcpy implementations so that we can frob the
+// Re-define the memcpy implementations so that we can frob the
 // interface to deal with possibly missing AVX instruction set support.
 
 #ifdef HAVE_AS_AVX
@@ -52,10 +48,10 @@ typedef float _ITM_TYPE_M256 __attribute__((vector_size(32), may_alias));
 #else
 /* Emit vmovaps (%rax),%ymm0.  */
 #define RETURN(X) \
-  asm volatile(".byte 0xc5,0xfc,0x28,0x00" : "=m"(X) : "a"(&X));
+  asm volatile(".byte 0xc5,0xfc,0x28,0x00" : "=m"(X) : "a"(&X))
 /* Emit vmovaps %ymm0,(%rax); vzeroupper.  */
 #define STORE(X,Y) \
-  asm volatile(".byte 0xc5,0xfc,0x29,0x00,0xc5,0xf8,0x77" : "=m"(X) : "a"(&X));
+  asm volatile(".byte 0xc5,0xfc,0x29,0x00,0xc5,0xf8,0x77" : "=m"(X) : "a"(&X))
 #define OUTPUT(T)	void
 #define INPUT(T,X)
 #endif
@@ -92,4 +88,4 @@ _ITM_LM256 (const _ITM_TYPE_M256 *ptr)
   GTM::GTM_LB (ptr, sizeof (*ptr));
 }
 
-}
+} // extern "C"
diff --git a/libitm/configure b/libitm/configure
index b30ced1..c0317cc 100644
--- a/libitm/configure
+++ b/libitm/configure
@@ -603,6 +603,8 @@ LTLIBOBJS
 LIBOBJS
 ARCH_FUTEX_FALSE
 ARCH_FUTEX_TRUE
+ARCH_X86_AVX_FALSE
+ARCH_X86_AVX_TRUE
 ARCH_X86_FALSE
 ARCH_X86_TRUE
 link_itm
@@ -11714,7 +11716,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 11717 "configure"
+#line 11719 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -11820,7 +11822,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 11823 "configure"
+#line 11825 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -17265,6 +17267,14 @@ else
   ARCH_X86_FALSE=
 fi
 
+ if test "$libitm_cv_as_avx" = yes; then
+  ARCH_X86_AVX_TRUE=
+  ARCH_X86_AVX_FALSE='#'
+else
+  ARCH_X86_AVX_TRUE='#'
+  ARCH_X86_AVX_FALSE=
+fi
+
  if test $enable_linux_futex = yes; then
   ARCH_FUTEX_TRUE=
   ARCH_FUTEX_FALSE='#'
@@ -17418,6 +17428,10 @@ if test -z "${ARCH_X86_TRUE}" && test -z "${ARCH_X86_FALSE}"; then
   as_fn_error "conditional \"ARCH_X86\" was never defined.
 Usually this means the macro was only invoked conditionally." "$LINENO" 5
 fi
+if test -z "${ARCH_X86_AVX_TRUE}" && test -z "${ARCH_X86_AVX_FALSE}"; then
+  as_fn_error "conditional \"ARCH_X86_AVX\" was never defined.
+Usually this means the macro was only invoked conditionally." "$LINENO" 5
+fi
 if test -z "${ARCH_FUTEX_TRUE}" && test -z "${ARCH_FUTEX_FALSE}"; then
   as_fn_error "conditional \"ARCH_FUTEX\" was never defined.
 Usually this means the macro was only invoked conditionally." "$LINENO" 5
diff --git a/libitm/configure.ac b/libitm/configure.ac
index 7de5cbe..672b712 100644
--- a/libitm/configure.ac
+++ b/libitm/configure.ac
@@ -272,6 +272,7 @@ fi
 AC_SUBST(link_itm)
 
 AM_CONDITIONAL([ARCH_X86], [test "$ARCH" = x86])
+AM_CONDITIONAL([ARCH_X86_AVX], [test "$libitm_cv_as_avx" = yes])
 AM_CONDITIONAL([ARCH_FUTEX], [test $enable_linux_futex = yes])
 
 AC_CONFIG_FILES(Makefile testsuite/Makefile libitm.spec)

Re: [libitm] Work around missing AVX support

[Iain Sandoe]

On 10 Nov 2011, at 17:12, Richard Henderson wrote:

> On 11/10/2011 12:16 AM, Jakub Jelinek wrote:
>> On Wed, Nov 09, 2011 at 04:32:58PM -0800, Richard Henderson wrote:
>>> Not pretty at all.  But given the corresponding irritation in  
>>> writing assembler
>>> wrapper functions, it seems like it's about a wash.
>>>
>>> Tested with and without HAVE_AS_AVX on x86_64-linux.
>> Shouldn't -mavx be also not passed in that case?  Then you wouldn't  
>> need
>> to undef __AVX__ and we wouldn't risk gcc doesn't decide to  
>> optimize memcpy
>> or something similar using AVX instructions...
>>
> You are correct.  Thanks for noticing this; I was a bit frazzled  
> after fighting with autofoo for so long yesterday.
>
> Tested on x86_64-linux, with avx and with avx forcibly disabled.

As of r181262 things are looking much better; all the files build ...

... we now have the following failure linking the library on i686- 
darwin9 and x86-64-darwin10:

libtool: link: /GCC/gcc-4-7-trunk-build/./gcc/xgcc -B/GCC/gcc-4-7- 
trunk-build/./gcc/ -B/GCC/gcc-4-7-install/i686-apple-darwin9/bin/ -B/ 
GCC/gcc-4-7-install/i686-apple-darwin9/lib/ -isystem /GCC/gcc-4-7- 
install/i686-apple-darwin9/include -isystem /GCC/gcc-4-7-install/i686- 
apple-darwin9/sys-include  -m64 -dynamiclib -Wl,-undefined - 
Wl,dynamic_lookup -o .libs/libitm.0.dylib  .libs/aatree.o .libs/ 
alloc.o .libs/alloc_c.o .libs/alloc_cpp.o .libs/barrier.o .libs/ 
beginend.o .libs/clone.o .libs/eh_cpp.o .libs/local.o .libs/ 
query.o .libs/retry.o .libs/rwlock.o .libs/useraction.o .libs/ 
util.o .libs/sjlj.o .libs/tls.o .libs/method-serial.o .libs/method- 
gl.o .libs/x86_sse.o .libs/x86_avx.o    -m64 -pthread -pthread -m64 - 
m64   -pthread -install_name  /GCC/gcc-4-7-install/lib/gcc/i686-apple- 
darwin9/4.7.0/x86_64/libitm.0.dylib -compatibility_version 1 - 
current_version 1.0 -Wl,-single_module
ld: codegen problem, can't use rel32 to external symbol in  
__ITM_malloc from .libs/alloc_c.o
collect2: error: ld returned 1 exit status

(I think the symbol in question is an __emutls var)

... the objects appear to be correctly x86-64 and the link line has "- 
m64" ... so there's a codegen issue somewhere, will try an investigate  
tomorrow.

--

The m32 version builds OK on i686-darwin9 (haven't been able to try on  
Darwin10 .. machine is busy)

Iain

Re: [libitm] Work around missing AVX support

[Patrick Marlier]

On 11/10/2011 03:25 PM, Iain Sandoe wrote:
> libtool: link: /GCC/gcc-4-7-trunk-build/./gcc/xgcc
> -B/GCC/gcc-4-7-trunk-build/./gcc/
> -B/GCC/gcc-4-7-install/i686-apple-darwin9/bin/
> -B/GCC/gcc-4-7-install/i686-apple-darwin9/lib/ -isystem
> /GCC/gcc-4-7-install/i686-apple-darwin9/include -isystem
> /GCC/gcc-4-7-install/i686-apple-darwin9/sys-include -m64 -dynamiclib
> -Wl,-undefined -Wl,dynamic_lookup -o .libs/libitm.0.dylib .libs/aatree.o
> .libs/alloc.o .libs/alloc_c.o .libs/alloc_cpp.o .libs/barrier.o
> .libs/beginend.o .libs/clone.o .libs/eh_cpp.o .libs/local.o
> .libs/query.o .libs/retry.o .libs/rwlock.o .libs/useraction.o
> .libs/util.o .libs/sjlj.o .libs/tls.o .libs/method-serial.o
> .libs/method-gl.o .libs/x86_sse.o .libs/x86_avx.o -m64 -pthread -pthread
> -m64 -m64 -pthread -install_name
> /GCC/gcc-4-7-install/lib/gcc/i686-apple-darwin9/4.7.0/x86_64/libitm.0.dylib
> -compatibility_version 1 -current_version 1.0 -Wl,-single_module
> ld: codegen problem, can't use rel32 to external symbol in __ITM_malloc
> from .libs/alloc_c.o
> collect2: error: ld returned 1 exit status
>
> (I think the symbol in question is an __emutls var)

The symbol _ITM_malloc is in libitm. Maybe the problem is an extra _ 
before the _ITM_malloc?

Patrick.

Re: [libitm] Work around missing AVX support

[Iain Sandoe]

On 10 Nov 2011, at 20:33, Patrick Marlier wrote:

> On 11/10/2011 03:25 PM, Iain Sandoe wrote:
>> libtool: link: /GCC/gcc-4-7-trunk-build/./gcc/xgcc
>> -B/GCC/gcc-4-7-trunk-build/./gcc/
>> -B/GCC/gcc-4-7-install/i686-apple-darwin9/bin/
>> -B/GCC/gcc-4-7-install/i686-apple-darwin9/lib/ -isystem
>> /GCC/gcc-4-7-install/i686-apple-darwin9/include -isystem
>> /GCC/gcc-4-7-install/i686-apple-darwin9/sys-include -m64 -dynamiclib
>> -Wl,-undefined -Wl,dynamic_lookup -o .libs/libitm.0.dylib .libs/ 
>> aatree.o
>> .libs/alloc.o .libs/alloc_c.o .libs/alloc_cpp.o .libs/barrier.o
>> .libs/beginend.o .libs/clone.o .libs/eh_cpp.o .libs/local.o
>> .libs/query.o .libs/retry.o .libs/rwlock.o .libs/useraction.o
>> .libs/util.o .libs/sjlj.o .libs/tls.o .libs/method-serial.o
>> .libs/method-gl.o .libs/x86_sse.o .libs/x86_avx.o -m64 -pthread - 
>> pthread
>> -m64 -m64 -pthread -install_name
>> /GCC/gcc-4-7-install/lib/gcc/i686-apple-darwin9/4.7.0/x86_64/libitm. 
>> 0.dylib
>> -compatibility_version 1 -current_version 1.0 -Wl,-single_module
>> ld: codegen problem, can't use rel32 to external symbol in  
>> __ITM_malloc
>> from .libs/alloc_c.o
>> collect2: error: ld returned 1 exit status
>>
>> (I think the symbol in question is an __emutls var)
>
> The symbol _ITM_malloc is in libitm. Maybe the problem is an extra _  
> before the _ITM_malloc?

Actually, I think the missing symbol is   
___emutls_v._ZN3GTM12_gtm_thr_tlsE
and (although the m32 lib builds OK - the symbol is also missing there).

The m64 build fails because of the -Wl,-undefined -Wl,dynamic_lookup  
in combination with the missing var.

the m32 build succeed - but none of the testsuite runs, because the  
emutls var is missing (not resolved at load).

----

... I strongly suspect it might be another manifestation of:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50598

Has anyone succeeded in building libitm on an emutls target?

Iain

Re: [libitm] Work around missing AVX support

[Iain Sandoe]

On 10 Nov 2011, at 20:43, Iain Sandoe wrote:
>> The symbol _ITM_malloc is in libitm. Maybe the problem is an extra  
>> _ before the _ITM_malloc?
>
> Actually, I think the missing symbol is   
> ___emutls_v._ZN3GTM12_gtm_thr_tlsE
> and (although the m32 lib builds OK - the symbol is also missing  
> there).
>
> The m64 build fails because of the -Wl,-undefined -Wl,dynamic_lookup

FAOD, Is there some reason that this library needs to resolve symbols  
from some external source at load time?

> in combination with the missing var.
> the m32 build succeed - but none of the testsuite runs, because the  
> emutls var is missing (not resolved at load).
>
> ----
>
> ... I strongly suspect it might be another manifestation of:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50598

This is confirmed - if I hack around that bug, the library builds.

There are two other issues I can see so far:

1/ the symbols generated in sjlj.S are not getting their extra "_" (I  
patched that up temporarily manually) ... which allows some of the  
testsuite to pass.

2/ The section .tm_clone_table doesn't exist for Darwin leading to  
assembler errors because ".tm_clone_table" is not a complete section  
spec for Darwin
(that's not too hard to fix - but too late for tonight).

Iain

Re: [libitm] Work around missing AVX support

[Jack Howarth]

On Thu, Nov 10, 2011 at 11:29:35PM +0000, Iain Sandoe wrote:
>
> On 10 Nov 2011, at 20:43, Iain Sandoe wrote:
>>> The symbol _ITM_malloc is in libitm. Maybe the problem is an extra _ 
>>> before the _ITM_malloc?
>>
>> Actually, I think the missing symbol is   
>> ___emutls_v._ZN3GTM12_gtm_thr_tlsE
>> and (although the m32 lib builds OK - the symbol is also missing  
>> there).
>>
>> The m64 build fails because of the -Wl,-undefined -Wl,dynamic_lookup
>
> FAOD, Is there some reason that this library needs to resolve symbols  
> from some external source at load time?
>
>> in combination with the missing var.
>> the m32 build succeed - but none of the testsuite runs, because the  
>> emutls var is missing (not resolved at load).
>>
>> ----
>>
>> ... I strongly suspect it might be another manifestation of:
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50598
>
> This is confirmed - if I hack around that bug, the library builds.

Iain,
   I can confirm on x86_64-apple-darwin11 that if I revert r179429...

	* cgraphunit.c (ipa_passes): Remove unrechable nodes.
	* lto-streamer-out.c (produce_symtab): Skip unused extern declarations.
	* ipa.c (cgraph_remove_unreachable_nodes): Do not assume that external
	functions are reachable when address is taken.
	* ipa-inline-analysis.c (reset_inline_edge_summary): New

	* gcc.dg/ipa/ctor-empty-1.c: Update dump file.

the linker crash is eliminated when libitm.dylib is linked.
                   Jack

>
> There are two other issues I can see so far:
>
> 1/ the symbols generated in sjlj.S are not getting their extra "_" (I  
> patched that up temporarily manually) ... which allows some of the  
> testsuite to pass.
>
> 2/ The section .tm_clone_table doesn't exist for Darwin leading to  
> assembler errors because ".tm_clone_table" is not a complete section  
> spec for Darwin
> (that's not too hard to fix - but too late for tonight).
>
> Iain

Re: [libitm] Work around missing AVX support

[Richard Henderson]

On 11/10/2011 03:29 PM, Iain Sandoe wrote:
>> The m64 build fails because of the -Wl,-undefined -Wl,dynamic_lookup
> 
> FAOD, Is there some reason that this library needs to resolve symbols
> from some external source at load time?

Not that I know of.  I think that's generic libtool giving you that.


r~

Re: [libitm] Work around missing AVX support

[Iain Sandoe]

An update .. in case anyone is following...

On 11 Nov 2011, at 00:21, Richard Henderson wrote:

> On 11/10/2011 03:29 PM, Iain Sandoe wrote:
>>> The m64 build fails because of the -Wl,-undefined -Wl,dynamic_lookup
>>
>> FAOD, Is there some reason that this library needs to resolve symbols
>> from some external source at load time?
>
> Not that I know of.  I think that's generic libtool giving you that.

hmmm. Some things are not stacking up.

If I:
a) patch around PR50596.
b) patch sjls.S to include the leading "_" on _ITM_beginTransaction  
and GTM_longjmp.
c) patch varasm to use "__DATA,__tm_clone_table" for the  
tm_clone_table section name.

most of the test-suite runs on x86-64-darwin10 (with fails on clone,  
memcpy, memset).
mem{cpy,set} are caused by a different naming for MAP_ANON (vs.  
MAP_ANONYMOUS).

however, most of the suite fails on darwin9 - with an undefined  
reference to delete(void*).

This is all puzzling me - because the Makefile.am contains

# Force link with C, not C++.  For now, while we're using C++ we don't
# want or need libstdc++.
libitm_la_LINK = $(LINK)
libitm_la_LDFLAGS = $(libitm_version_info) $(libitm_version_script) \
         -no-undefined

===

however, if I hack the libtool to remove the  -Wl,-undefined - 
Wl,dynamic_lookup ...
... I get :

/GCC/gcc-4-7-trunk-build/./gcc/xgcc -B/GCC/gcc-4-7-trunk-build/./gcc/ - 
B/GCC/gcc-4-7-install/i686-apple-darwin9/bin/ -B/GCC/gcc-4-7-install/ 
i686-apple-darwin9/lib/ -isystem /GCC/gcc-4-7-install/i686-apple- 
darwin9/include -isystem /GCC/gcc-4-7-install/i686-apple-darwin9/sys- 
include    -dynamiclib  -o .libs/libitm.0.dylib  .libs/aatree.o .libs/ 
alloc.o .libs/alloc_c.o .libs/alloc_cpp.o .libs/barrier.o .libs/ 
beginend.o .libs/clone.o .libs/eh_cpp.o .libs/local.o .libs/ 
query.o .libs/retry.o .libs/rwlock.o .libs/useraction.o .libs/ 
util.o .libs/sjlj.o .libs/tls.o .libs/method-serial.o .libs/method- 
gl.o .libs/x86_sse.o .libs/x86_avx.o    -march=i486 -mtune=i686 - 
pthread   -install_name  /GCC/gcc-4-7-install/lib/gcc/i686-apple- 
darwin9/4.7.0/libitm.0.dylib -compatibility_version 1 -current_version  
1.0 -Wl,-single_module
Undefined symbols:
   "operator delete(void*, std::nothrow_t const&)", referenced from:
       _del_opnt in alloc_cpp.o
   "operator delete(void*)", referenced from:
       __ZdlPv$non_lazy_ptr in alloc_cpp.o
   "___cxa_tm_cleanup", referenced from:
        
GTM::gtm_thread::revert_cpp_exceptions(GTM::gtm_transaction_cp*)       
in eh_cpp.o
        
GTM::gtm_thread::revert_cpp_exceptions(GTM::gtm_transaction_cp*)       
in eh_cpp.o
   "operator new[](unsigned long)", referenced from:
       transaction clone for operator new[](unsigned long) in  
alloc_cpp.o
   "operator delete[](void*)", referenced from:
       __ZdaPv$non_lazy_ptr in alloc_cpp.o
   "___cxa_begin_catch", referenced from:
       __ITM_cxa_begin_catch in eh_cpp.o
   "operator delete[](void*, std::nothrow_t const&)", referenced from:
       _del_opvnt in alloc_cpp.o
   "operator new[](unsigned long, std::nothrow_t const&)", referenced  
from:
       transaction clone for operator new[](unsigned long,  
std::nothrow_t const&) in alloc_cpp.o
   "operator new(unsigned long, std::nothrow_t const&)", referenced  
from:
       transaction clone for operator new(unsigned long,  
std::nothrow_t const&) in alloc_cpp.o
   "operator new(unsigned long)", referenced from:
       transaction clone for operator new(unsigned long) in alloc_cpp.o
   "___cxa_allocate_exception", referenced from:
       __ITM_cxa_allocate_exception in eh_cpp.o
   "___cxa_throw", referenced from:
       __ITM_cxa_throw in eh_cpp.o
   "___cxa_end_catch", referenced from:
       __ITM_cxa_end_catch in eh_cpp.o
ld: symbol(s) not found

i.e. a bunch of undefined c++ symbols...

(have to do some other stuff for a while.. will try to get back o this  
later).

Iain

Re: [libitm] Work around missing AVX support

[Rainer Orth]

Iain Sandoe <developer@sandoe-acoustics.co.uk> writes:

> however, most of the suite fails on darwin9 - with an undefined reference
> to delete(void*).

Could this be the same issue I've been seeing on Tru64 UNIX, i.e. lack
of weakdef support?

	http://gcc.gnu.org/ml/gcc-patches/2011-11/msg01426.html

At least my weakdef.c testcase also fails to link on
i386-apple-darwin9.8.0.

	Rainer

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

Re: [libitm] Work around missing AVX support

[Iain Sandoe]

On 11 Nov 2011, at 14:33, Rainer Orth wrote:

> Iain Sandoe <developer@sandoe-acoustics.co.uk> writes:
>
>> however, most of the suite fails on darwin9 - with an undefined  
>> reference
>> to delete(void*).
>
> Could this be the same issue I've been seeing on Tru64 UNIX, i.e. lack
> of weakdef support?
>
> 	http://gcc.gnu.org/ml/gcc-patches/2011-11/msg01426.html
>
> At least my weakdef.c testcase also fails to link on
> i386-apple-darwin9.8.0.

It certainly looks similar to point 2

Having discussed this with Mike and tried out some experiments.

For Darwin, the symbol can be absent at runtime (and will compare to  
NULL as per the elf case).

However,

a) (with two-level namespace) it can't be absent at link time  - so  
there has to be a dummy provided there.

b) (If you force flat_namespace ... which IMO would be a Very Bad  
Thing for the compiler) you can do
-flat_namespace -undefined suppress  ...
... see the discussion in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51059

- so I think that is quite similar to what your quoted page is saying?

However,

...  it doesn't explain why x86-64 Darwin10 does NOT seem to  
experience this (there should be no change in weak semantics AFAIK  
between 9 and 10) .
     .. and i686-darwin9 does (unless there's a tool bug in Darwin 9  
that this is exposing).

... and the comment stands that the Makefile.am explicitly says "we  
don't want or need libstdc++" but the missing symbols (in darwin9)  
seem to be from there.

cheers
Iain