[Bug c/43553] New: libgcc built with -DHAVE_CC_TLS against xgcc when emutls in use

[Bug c/43553] New: libgcc built with -DHAVE_CC_TLS against xgcc when emutls in use

[howarth at nitro dot med dot uc dot edu]

While testing the proposed patch to eliminate race conditions in indirect value
profiling...

http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00892.html

I found that the many profile testcases failed due unresolved symbols such
as...
__emutls_v.__gcov_indirect_call_counters and
___emutls_v.__gcov_indirect_call_callee".
A review of the later stage libgcc builds revealed that the -DHAVE_CC_TLS flag
was passed
without the associated -DUSE_EMUTLS. The current test for setting -DHAVE_CC_TLS
is based
on the test program...

__thread int a; int b; int main() { return a = b; }

which while it fails under the Apple system gcc 4.2.1 compiler with the
error...

thread_test.c:1: error: thread-local storage not supported for this target

compiles without error and runs fine under the newly built xgcc compiler (due
to
the emutls support). The easy fix appears to be...

2010-03-27  Jack Howarth <howarth@bromo.med.uc.edu>

        * config.host (tmake_file): Add t-emutls for *-*-darwin*.
        * t-emutls: New file.

Index: libgcc/config.host
===================================================================
--- libgcc/config.host  (revision 157779)
+++ libgcc/config.host  (working copy)
@@ -597,6 +597,12 @@
 esac

 case ${host} in
+*-*-darwin*)
+       tmake_file="${tmake_file} t-emutls"
+       ;;
+esac
+
+case ${host} in
 i[34567]86-*-darwin* | x86_64-*-darwin* | \
   i[34567]86-*-kfreebsd*-gnu | x86_64-*-kfreebsd*-gnu | \
   i[34567]86-*-linux* | x86_64-*-linux* | \
Index: libgcc/config/t-emutls 
===================================================================
--- libgcc/config/t-emutls      (revision 0)
+++ libgcc/config/t-emutls      (revision 0)
@@ -0,0 +1,2 @@
+# Use emulated thread-local storage
+INTERNAL_CFLAGS += -DUSE_EMUTLS

which bootstraps fine on both x86_64-apple-darwin9 and x86_64-apple-darwin10
with the proposed race condition patch...

Index: gcc/tree-profile.c
===================================================================
--- gcc/tree-profile.c  (revision 157765)
+++ gcc/tree-profile.c  (working copy)
@@ -82,6 +82,7 @@
   TREE_PUBLIC (ic_void_ptr_var) = 0;
   DECL_ARTIFICIAL (ic_void_ptr_var) = 1;
   DECL_INITIAL (ic_void_ptr_var) = NULL;
+  DECL_TLS_MODEL (ic_void_ptr_var) = decl_default_tls_model (ic_void_ptr_var);
   varpool_finalize_decl (ic_void_ptr_var);

   gcov_type_ptr = build_pointer_type (get_gcov_type ());
@@ -93,6 +94,7 @@
   TREE_PUBLIC (ic_gcov_type_ptr_var) = 0;
   DECL_ARTIFICIAL (ic_gcov_type_ptr_var) = 1;
   DECL_INITIAL (ic_gcov_type_ptr_var) = NULL;
+  DECL_TLS_MODEL (ic_gcov_type_ptr_var) = decl_default_tls_model
(ic_gcov_type_ptr_var);
   varpool_finalize_decl (ic_gcov_type_ptr_var);
 }

with no regressions in the testsuite (particularly the profile section). I
assume when the race
condition fix is committed other targets that use emutls will need to be added
to the 
case statement.


-- 
           Summary: libgcc built with -DHAVE_CC_TLS against xgcc when emutls
                    in use
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: howarth at nitro dot med dot uc dot edu
 GCC build triplet: *-apple-darwin*
  GCC host triplet: *-apple-darwin*
GCC target triplet: *-apple-darwin*


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43553

[Bug c/43553] libgcc built with -DHAVE_CC_TLS against xgcc when emutls in use

[howarth at nitro dot med dot uc dot edu]

------- Comment #1 from howarth at nitro dot med dot uc dot edu  2010-03-28 02:07 -------
I based my proposed patch roughly on the orginal patch that introduced the use
of -DHAVE_CC_TLS.

Author: hjl
Date: Fri Jul  6 14:00:46 2007
New Revision: 126416

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126416
Log:
config/

2007-07-06  H.J. Lu  <hongjiu.lu@intel.com>

        * tls.m4 (GCC_CHECK_CC_TLS): New.

libgcc/

2007-07-06  H.J. Lu  <hongjiu.lu@intel.com>

        * config.host (tmake_file): Add t-tls for i[34567]86-*-linux*
        and x86_64-*-linux*.

        * config/t-tls: New file.

        * Makefile.in (INTERNAL_CFLAGS): Add @set_have_cc_tls@. 

        * configure.ac: Include ../config/enable.m4 and
        ../config/tls.m4.  Use GCC_CHECK_CC_TLS to check if assembler
        supports TLS and substitute set_have_cc_tls.
        * configure: Regenerated.

libbid/

2007-07-06  H.J. Lu  <hongjiu.lu@intel.com>

        Updated from Intel BID library:
        * bid_conf.h (BID_THREAD): Defined only if both HAVE_CC_TLS
        and USE_TLS are defined.

Added:
    trunk/libgcc/config/t-tls
Modified:
    trunk/config/ChangeLog
    trunk/config/tls.m4
    trunk/libgcc/ChangeLog
    trunk/libgcc/Makefile.in
    trunk/libgcc/config.host
    trunk/libgcc/config/libbid/ChangeLog
    trunk/libgcc/config/libbid/bid_conf.h
    trunk/libgcc/configure
    trunk/libgcc/configure.ac


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43553

[Bug c/43553] libgcc built with -DHAVE_CC_TLS against xgcc when emutls in use

[howarth at nitro dot med dot uc dot edu]

------- Comment #2 from howarth at nitro dot med dot uc dot edu  2010-03-28 02:16 -------
Created an attachment (id=20226)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20226&action=view)
proposed patch to pass -DUSE_EMUTLS via libgcc/config/t-emutls on darwin


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43553

[Bug c/43553] libgcc built with -DHAVE_CC_TLS against xgcc when emutls in use

[howarth at nitro dot med dot uc dot edu]

------- Comment #3 from howarth at nitro dot med dot uc dot edu  2010-03-28 04:39 -------
Regression testing of t-emutls.diff patch on x86_64-apple-darwin9 and
x86_64-apple-darwin10 at...

http://gcc.gnu.org/ml/gcc-testresults/2010-03/msg02419.html
http://gcc.gnu.org/ml/gcc-testresults/2010-03/msg02428.html


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43553

[Bug c/43553] libgcc built with -DHAVE_CC_TLS against xgcc when emutls in use

[howarth at nitro dot med dot uc dot edu]

------- Comment #4 from howarth at nitro dot med dot uc dot edu  2010-03-28 05:49 -------
Created an attachment (id=20227)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20227&action=view)
revised proposed patch to pass -DUSE_EMUTLS via libgcc/config/t-emutls on
darwin


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43553

[Bug c/43553] libgcc built with -DHAVE_CC_TLS against xgcc when emutls in use

[howarth at nitro dot med dot uc dot edu]

------- Comment #5 from howarth at nitro dot med dot uc dot edu  2010-03-28 16:11 -------
Created an attachment (id=20232)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20232&action=view)
proposed patch to pass -DUSE_EMUTLS via libgcc/config/t-emutls on darwin

Corrected ChangeLog and comment.


-- 

howarth at nitro dot med dot uc dot edu changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #20227|0                           |1
        is obsolete|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43553

[Bug c/43553] libgcc built with -DHAVE_CC_TLS against xgcc when emutls in use

[howarth at nitro dot med dot uc dot edu]

------- Comment #6 from howarth at nitro dot med dot uc dot edu  2010-03-28 16:29 -------
Testsuite results for revised patch at
http://gcc.gnu.org/ml/gcc-testresults/2010-03/msg02449.html.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43553

[Bug c/43553] libgcc built with -DHAVE_CC_TLS against xgcc when emutls in use

[howarth at nitro dot med dot uc dot edu]

------- Comment #7 from howarth at nitro dot med dot uc dot edu  2010-03-28 19:21 -------
Untested alternative approach to fix this...

Index: libgcc/Makefile.in
===================================================================
--- libgcc/Makefile.in  (revision 157785)
+++ libgcc/Makefile.in  (working copy)
@@ -226,7 +226,7 @@
 # will usually contain -g, so for the moment CFLAGS goes first.  We must
 # include CFLAGS - that's where multilib options live.
 INTERNAL_CFLAGS = $(CFLAGS) $(LIBGCC2_CFLAGS) $(HOST_LIBGCC2_CFLAGS) \
-                 $(INCLUDES) @set_have_cc_tls@
+                 $(INCLUDES) @set_have_cc_tls@ @set_use_emutls@

 MULTIDIR := $(shell $(CC) $(CFLAGS) -print-multi-directory)
 MULTIOSDIR := $(shell $(CC) $(CFLAGS) -print-multi-os-directory)
Index: libgcc/configure.ac
===================================================================
--- libgcc/configure.ac (revision 157785)
+++ libgcc/configure.ac (working copy)
@@ -238,6 +238,14 @@
 fi
 AC_SUBST(set_have_cc_tls)

+# See if we have emulated thread-local storage.
+GCC_CHECK_EMUTLS
+set_use_emutls=
+if test "$enable_tls $gcc_cv_use_emutls" = "yes yes"; then
+  set_use_emutls="-DUSE_EMUTLS"
+fi
+AC_SUBST(set_use_emutls)
+
 # Conditionalize the makefile for this target machine.
 tmake_file_=
 for f in ${tmake_file}


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43553

[Bug c/43553] libgcc built with -DHAVE_CC_TLS against xgcc when emutls in use

[howarth at nitro dot med dot uc dot edu]

------- Comment #8 from howarth at nitro dot med dot uc dot edu  2010-03-28 20:31 -------
Created an attachment (id=20233)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20233&action=view)
alternative patch that uses GCC_CHECK_EMUTLS and set_use_emutls


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43553

[Bug c/43553] libgcc built with -DHAVE_CC_TLS against xgcc when emutls in use

[howarth at nitro dot med dot uc dot edu]

------- Comment #9 from howarth at nitro dot med dot uc dot edu  2010-03-28 20:59 -------
Confirmed with current gcc trunk on x86_64 Fedora 10 that the alternative patch
which uses GCC_CHECK_EMUTLS still leaves the build properly passing
-DHAVE_CC_TLS  -DUSE_TLS for native TLS targets. 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43553

[Bug c/43553] libgcc built with -DHAVE_CC_TLS against xgcc when emutls in use

[rguenth at gcc dot gnu dot org]

------- Comment #11 from rguenth at gcc dot gnu dot org  2010-03-30 13:09 -------
Subject: Bug 43553

Author: rguenth
Date: Tue Mar 30 13:08:52 2010
New Revision: 157821

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157821
Log:
2010-03-30  Jack Howarth <howarth@bromo.med.uc.edu>

        PR c/43553
        * Makefile.in (INTERNAL_CFLAGS): Add @set_use_emutls@.
        * configure.ac: Use GCC_CHECK_EMUTLS to see if emulated TLS
        is used and substitute set_use_emutls.
        * configure: Regenerated.

Modified:
    trunk/libgcc/ChangeLog
    trunk/libgcc/Makefile.in
    trunk/libgcc/configure
    trunk/libgcc/configure.ac


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43553

[Bug c/43553] libgcc built with -DHAVE_CC_TLS against xgcc when emutls in use

[rguenth at gcc dot gnu dot org]

------- Comment #12 from rguenth at gcc dot gnu dot org  2010-03-30 16:01 -------
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43553

[Bug c/43553] libgcc built with -DHAVE_CC_TLS against xgcc when emutls in use

[howarth at nitro dot med dot uc dot edu]

------- Comment #13 from howarth at nitro dot med dot uc dot edu  2010-03-31 02:16 -------
I was confused and the race condition patch wasn't actually applied to my tree
on darwin when I did the last set of tests. Current gcc trunk still fails the
profile related test cases on darwin with undefined symbols...

[MacPro:~] howarth%
/sw/src/fink.build/gcc45-4.4.999-20100330/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc45-4.4.999-20100330/darwin_objdir/gcc/
/sw/src/fink.build/gcc45-4.4.999-20100330/gcc-4.5-20100330/gcc/testsuite/gcc.dg/matrix/transpose-1.c
   -fprofile-generate -O3  -lm   -o
/sw/src/fink.build/gcc45-4.4.999-20100330/darwin_objdir/gcc/testsuite/gcc/transpose-1.x01
Undefined symbols:
  "___emutls_v.__gcov_indirect_call_counters", referenced from:
      _mem_init in cc591Wfh.o
      _main in cc591Wfh.o
      global constructors keyed to 65535_0_transpose_1.c in cc591Wfh.o
  "___emutls_v.__gcov_indirect_call_callee", referenced from:
      _mem_init in cc591Wfh.o
      _mem_init in cc591Wfh.o
      _main in cc591Wfh.o
      _main in cc591Wfh.o
      global constructors keyed to 65535_0_transpose_1.c in cc591Wfh.o
      global constructors keyed to 65535_0_transpose_1.c in cc591Wfh.o
ld: symbol(s) not found
collect2: ld returned 1 exit status

Reverting the race condition patch eliminates this problem. So the question
becomes is whether emulated tls expected to be sufficient for this task? I
tried the inverse of inhibiting the use of  -DHAVE_CC_TLS instead and  I still
get the same unresoived symbols.

Index: libgcc/Makefile.in
===================================================================
--- libgcc/Makefile.in  (revision 157840)
+++ libgcc/Makefile.in  (working copy)
@@ -226,7 +226,7 @@
 # will usually contain -g, so for the moment CFLAGS goes first.  We must
 # include CFLAGS - that's where multilib options live.
 INTERNAL_CFLAGS = $(CFLAGS) $(LIBGCC2_CFLAGS) $(HOST_LIBGCC2_CFLAGS) \
-                 $(INCLUDES) @set_have_cc_tls@ @set_use_emutls@
+                 $(INCLUDES) @set_have_cc_tls@

 MULTIDIR := $(shell $(CC) $(CFLAGS) -print-multi-directory)
 MULTIOSDIR := $(shell $(CC) $(CFLAGS) -print-multi-os-directory)
Index: libgcc/configure.ac
===================================================================
--- libgcc/configure.ac (revision 157840)
+++ libgcc/configure.ac (working copy)
@@ -232,20 +232,13 @@
 # gcc, which can't be used to build executable due to that libgcc
 # is yet to be built here.
 GCC_CHECK_CC_TLS
+GCC_CHECK_EMUTLS
 set_have_cc_tls=
-if test "$enable_tls $gcc_cv_have_cc_tls" = "yes yes"; then
+if test "$enable_tls $gcc_cv_have_cc_tls $gcc_cv_use_emutls" = "yes yes no";
then
   set_have_cc_tls="-DHAVE_CC_TLS"
 fi
 AC_SUBST(set_have_cc_tls)

-# See if we have emulated thread-local storage.
-GCC_CHECK_EMUTLS
-set_use_emutls=
-if test "$enable_tls $gcc_cv_use_emutls" = "yes yes"; then
-  set_use_emutls="-DUSE_EMUTLS"
-fi
-AC_SUBST(set_use_emutls)
-
 # Conditionalize the makefile for this target machine.
 tmake_file_=
 for f in ${tmake_file}


-- 

howarth at nitro dot med dot uc dot edu changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|FIXED                       |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43553

[Bug c/43553] libgcc built with -DHAVE_CC_TLS against xgcc when emutls in use

[howarth at nitro dot med dot uc dot edu]

------- Comment #14 from howarth at nitro dot med dot uc dot edu  2010-03-31 02:44 -------
I confused why the other instances of using DECL_TLS_MODEL() in gcc doesn't
trigger unresolved symbols on darwin. For instance in gcc/c-decl.c we have...

        if (threadp)
          DECL_TLS_MODEL (decl) = decl_default_tls_model (decl);
      }

which seems almost identical to the offending change in gcc/tree-profile.c...

DECL_TLS_MODEL (ic_void_ptr_var) = decl_default_tls_model (ic_void_ptr_var);

yet it doesn't seem to trigger unresolved symbols.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43553

[Bug c/43553] libgcc built with -DHAVE_CC_TLS against xgcc when emutls in use

[howarth at nitro dot med dot uc dot edu]

------- Comment #15 from howarth at nitro dot med dot uc dot edu  2010-03-31 03:53 -------
What other targets besides darwin rely on emulated tls? I would have guessed
powerpc64-*-linux* since it isn't listed in the section of libgcc/config.host
that enables native tls...

case ${host} in
i[34567]86-*-linux* | x86_64-*-linux* | \
  i[34567]86-*-kfreebsd*-gnu | i[34567]86-*-knetbsd*-gnu | \
  i[34567]86-*-gnu*)
        tmake_file="${tmake_file} t-tls"
        ;;
esac

yet I see that after the race condition patch commit at r157822, their
testresults show no profile testcase regressions
http://gcc.gnu.org/ml/gcc-testresults/2010-03/msg02646.html. This is very
strange since darwin is now exporting all the additional emutls symbols in via
libgcc_ext.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43553

[Bug c/43553] libgcc built with -DHAVE_CC_TLS against xgcc when emutls in use

[howarth at nitro dot med dot uc dot edu]

------- Comment #16 from howarth at nitro dot med dot uc dot edu  2010-03-31 06:15 -------
On x86_64-apple-darwin10, current gcc trunk produces...

[MacPro:darwin_objdir/x86_64-apple-darwin10.3.0/libgcc] howarth% nm
libgcc_s.1.dylib | grep emutls
00013e70 T ___emutls_get_address
00014070 T ___emutls_register_common
00013e20 t _emutls_destroy
00013de0 t _emutls_init
00015100 b _emutls_key
000150a0 d _emutls_mutex
000150fc b _emutls_size

[MacPro:darwin_objdir/x86_64-apple-darwin10.3.0/libgcc] howarth% nm
libgcc_ext.10.5.dylib | grep emutls
00013e70 T ___emutls_get_address
00014070 T ___emutls_register_common


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43553

[Bug c/43553] libgcc built with -DHAVE_CC_TLS against xgcc when emutls in use

[developer at sandoe-acoustics dot co dot uk]

------- Comment #17 from developer at sandoe-acoustics dot co dot uk  2010-04-01 08:02 -------
AFAICT the root problem does not relate to export of symbols from emutls (or to
its use).  Although this perhaps needs a different PR

The root problem is that the emutls implementation generates symbols in the
data area that are (AFAICT) translated into thread-unique addresses by
_emutls_get_address.

The two symbols in question are declared static and private and are being
optimized away.   (you will find that the profile tests work at -O0).

I am not sure why they are being optimized away when there is a reference to
them in the asm file -- see (b) below.

The variables need to be preserved and coalesced within one binary.

a/ A work-round solution is to mark the two variables PUBLIC and COMMON.  I've
tested that this works on i686-apple-darwin and ia32-pc-linux .... BUT....

b/ Looking at http://gcc.gnu.org/ml/gcc/2010-03/msg00482.html

It is perhaps the case that other attributes are not being copied that are
causing this problem.

Of course, maybe this is also a limitation of emutls.

I don't have time to do much on this today -- and the trunk freeze is fast
approaching.. input from more experienced would be welcome...


-- 

developer at sandoe-acoustics dot co dot uk changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |developer at sandoe-
                   |                            |acoustics dot co dot uk


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43553

[Bug c/43553] libgcc built with -DHAVE_CC_TLS against xgcc when emutls in use

[bonzini at gnu dot org]

------- Comment #18 from bonzini at gnu dot org  2010-04-01 08:08 -------
TREE_USED then?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43553

[Bug c/43553] libgcc built with -DHAVE_CC_TLS against xgcc when emutls in use

[developer at sandoe-acoustics dot co dot uk]

------- Comment #19 from developer at sandoe-acoustics dot co dot uk  2010-04-01 08:30 -------
(In reply to comment #18)
> TREE_USED then?

It doesn't do it... tried that first ;-)  [ and it is copied]
However, I see the comment that variables can change status during their life -
or perhaps it's a bug...

I also tried TREE_ADDRESSABLE  and DECL_PRESERVED_P - but now I see that these
are not copied.
hmmm


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43553

[Bug c/43553] libgcc built with -DHAVE_CC_TLS against xgcc when emutls in use

[developer at sandoe-acoustics dot co dot uk]

------- Comment #20 from developer at sandoe-acoustics dot co dot uk  2010-04-02 21:15 -------
(In reply to comment #18)
> TREE_USED then?

It looks to me like the problem is more subtle.
I think it is to do with the fact that the emutls variables are proxies for the
actual ones and that the proxies are not being finalized.

I've patched current tree (+ the tree-profile.c patch) with the one below ...  
... this fixes the unresolved vars problems ..  but, maybe causes one
regression in g++ and a few in libgomp.fortran,
I'm looking into those -- but would really welcome input from people who know
more about emutls.

Index: gcc/varpool.c
===================================================================
--- gcc/varpool.c       (revision 157942)
+++ gcc/varpool.c       (working copy)
@@ -281,6 +281,17 @@
 varpool_finalize_decl (tree decl)
 {
   struct varpool_node *node = varpool_node (decl);
+  
+  /* When emulating tls, we actually see references to the control
+     variable, rather than the user-level variable.  Make sure that 
+     these control variables are finalized. */
+  if (!targetm.have_tls
+      && TREE_CODE (decl) == VAR_DECL
+      && DECL_THREAD_LOCAL_P (decl))
+    {
+      tree control = emutls_decl (decl);
+      varpool_finalize_decl (control);
+    }

   /* FIXME: We don't really stream varpool datastructure and instead rebuild
it
      by varpool_finalize_decl.  This is not quite correct since this way we
can't


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43553

[Bug c/43553] libgcc built with -DHAVE_CC_TLS against xgcc when emutls in use

[developer at sandoe-acoustics dot co dot uk]

------- Comment #21 from developer at sandoe-acoustics dot co dot uk  2010-04-02 21:31 -------
(In reply to comment #20)

> I'm looking into those -- but would really welcome input from people who know
> more about emutls.

for example, is this really something that should be handled in some way from
emutls_finish()?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43553

[Bug c/43553] libgcc built with -DHAVE_CC_TLS against xgcc when emutls in use

[developer at sandoe-acoustics dot co dot uk]

------- Comment #22 from developer at sandoe-acoustics dot co dot uk  2010-04-03 11:00 -------
Created an attachment (id=20299)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20299&action=view)
finalize emutls control vars before varpool_assemble_ending_decls()

This provides a traverse of the emutls control var htab finalizing each.

It allows the race condition patch to be applied without regression.  

Hopefully, by inspection, it can be seen that targetm.have_tls will bypass this
and, therefore, this should only effect emutls targets.

I didn't try to check if vars were already finalized in the traversal callback
- on the basis that varpool_finalize_decl is efficient at that itself.  

Of course, the disclaimers are:
(a) I'm even newer to this area of gcc than others ;) so...
(b) there might be a much better/more efficient way/place to do this.

Additional:  following Paolo's comments on gcc I've updated emutls_decl() to
copy:
TREE_ADDRESSABLE, DECL_VISIBILITY_SPECIFIED, DECL_PRESERVE_P and DECL_INITAL.

I haven't made the efficiency improvement mod.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43553

[Bug c/43553] libgcc built with -DHAVE_CC_TLS against xgcc when emutls in use

[dominiq at lps dot ens dot fr]

------- Comment #23 from dominiq at lps dot ens dot fr  2010-04-03 20:03 -------
The patch in comment #22 works as advertised without new regression (see
http://gcc.gnu.org/ml/gcc-testresults/2010-04/msg00243.html).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43553

[Bug c/43553] libgcc built with -DHAVE_CC_TLS against xgcc when emutls in use

[bonzini at gnu dot org]

------- Comment #24 from bonzini at gnu dot org  2010-04-04 07:18 -------
Subject: Re:  libgcc built with -DHAVE_CC_TLS against xgcc when
 emutls in use


> This provides a traverse of the emutls control var htab finalizing
> each.
>
> I didn't try to check if vars were already finalized in the traversal
> callback - on the basis that varpool_finalize_decl is efficient at
> that itself.
>
> Additional:  following Paolo's comments on gcc I've updated
> emutls_decl() to copy: TREE_ADDRESSABLE, DECL_VISIBILITY_SPECIFIED,
> DECL_PRESERVE_P and DECL_INITAL.

The patch makes sense, only I'm not entirely sure copying the other
three fields is correct.  I'd have to see exactly how emutls decls are
used to review that.

For now, I'd update it to copy only DECL_VISIBILITY_SPECIFIED if it
works (as I interpret your comment that fixing emutls_decl was
"additional"), and leave the rest for 4.6.

Paolo


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43553

[Bug c/43553] libgcc built with -DHAVE_CC_TLS against xgcc when emutls in use

[howarth at nitro dot med dot uc dot edu]

------- Comment #25 from howarth at nitro dot med dot uc dot edu  2010-04-04 16:30 -------
Created an attachment (id=20305)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20305&action=view)
reduced version of 157942-emutls-finalize-diff.txt


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43553

[Bug c/43553] libgcc built with -DHAVE_CC_TLS against xgcc when emutls in use

[howarth at nitro dot med dot uc dot edu]

------- Comment #26 from howarth at nitro dot med dot uc dot edu  2010-04-04 16:33 -------
I can confirm on x86_64-apple-darwin10 that the reduced form of Iain's patch
(reduced_emutis.patch) eliminates all of the profile testcase regressions when
r157822 is reapplied to current gcc trunk. Iain can you post this to
gcc-patches with a ChangeLog?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43553

[Bug c/43553] libgcc built with -DHAVE_CC_TLS against xgcc when emutls in use

[howarth at nitro dot med dot uc dot edu]

------- Comment #27 from howarth at nitro dot med dot uc dot edu  2010-04-04 17:58 -------
Testsuite results for the reduced version of the
157942-emutls-finalize-diff.txt patch and r157822 reapplied to gcc trunk at
r157958 are posted at...

http://gcc.gnu.org/ml/gcc-testresults/2010-04/msg00318.html


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43553

[Bug c/43553] libgcc built with -DHAVE_CC_TLS against xgcc when emutls in use

[developer at sandoe-acoustics dot co dot uk]

------- Comment #28 from developer at sandoe-acoustics dot co dot uk  2010-04-04 20:18 -------
(In reply to comment #26)
> Iain can you post this to  gcc-patches with a ChangeLog?

Well, I guess it seems to do the job (I reverted the additional copies in
emutls_decl() on my local branch and re-checked).

Hmm.  Well, it would be good to get a review form the emutls authors - but I
guess this is a busy time.

IMO - this PR should be closed as fixed by the -DUSE_EMUTLS patch .. and the
patch I've proposed should probably be attached to 43602.

Also - AFAICT there's no reason for a few of the test-suite tls entries to be
marked as requiring tls_native (tls would do).  So I'll put together two
patches - a reduced version of the one attached here and a patch that allows
more of the g++ tls tests to run on emutls targets.

I'll mark them as solving PR43602 (and this one if you like)...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43553

[Bug c/43553] libgcc built with -DHAVE_CC_TLS against xgcc when emutls in use

[howarth at nitro dot med dot uc dot edu]

------- Comment #29 from howarth at nitro dot med dot uc dot edu  2010-04-04 21:08 -------
Iain,
   Do please post the revised patch to gcc-patches with a changelog. That may
incite a review from the emutls maintainers.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43553

[Bug c/43553] libgcc built with -DHAVE_CC_TLS against xgcc when emutls in use

[developer at sandoe-acoustics dot co dot uk]

------- Comment #30 from developer at sandoe-acoustics dot co dot uk  2010-04-05 08:33 -------
(In reply to comment #29)
> Iain,
>    Do please post the revised patch to gcc-patches with a changelog. That may
> incite a review from the emutls maintainers.

see: http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00129.html


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43553

[Bug c/43553] libgcc built with -DHAVE_CC_TLS against xgcc when emutls in use

[iains at gcc dot gnu dot org]

------- Comment #31 from iains at gcc dot gnu dot org  2010-05-25 12:51 -------
please can we revert the changes of comment #11?

They did not solve the problem and AFAICT they are wrong and break bootstrap on
x86_64-apple-darwin10 if I correct an error in the t-makefile fragments.  

after that, surely this bug can now be closed?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43553

[Bug c/43553] libgcc built with -DHAVE_CC_TLS against xgcc when emutls in use

[mrs at gcc dot gnu dot org]

------- Comment #32 from mrs at gcc dot gnu dot org  2010-05-27 15:10 -------
I'd like to hear what Jack has to say, otherwise, fine by me.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43553

[Bug c/43553] libgcc built with -DHAVE_CC_TLS against xgcc when emutls in use

[howarth at nitro dot med dot uc dot edu]

------- Comment #33 from howarth at nitro dot med dot uc dot edu  2010-05-28 00:02 -------
(In reply to comment #32)
> I'd like to hear what Jack has to say, otherwise, fine by me.
> 

No objections here.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43553

[Bug c/43553] libgcc built with -DHAVE_CC_TLS against xgcc when emutls in use

[howarth at nitro dot med dot uc dot edu]

------- Comment #34 from howarth at nitro dot med dot uc dot edu  2010-08-20 11:39 -------
No breakage in current bootstrap.


-- 

howarth at nitro dot med dot uc dot edu changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43553