[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.

[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.

[pinskia at gcc dot gnu.org]

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

--- Comment #44 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 44450 has been marked as a duplicate of this bug. ***

[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.

[rth at gcc dot gnu dot org]

------- Comment #43 from rth at gcc dot gnu dot org  2010-07-26 22:58 -------
Emutls now re-written in a way that should support LTO.


-- 

rth at gcc dot gnu dot org changed:

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


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

[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.

[rth at gcc dot gnu dot org]

------- Comment #42 from rth at gcc dot gnu dot org  2010-07-26 22:54 -------
Subject: Bug 44132

Author: rth
Date: Mon Jul 26 22:53:50 2010
New Revision: 162549

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162549
Log:
PR target/44132
Emulated TLS rewrite.

Added:
    trunk/gcc/testsuite/gcc.dg/tls/emutls-2.c
    trunk/gcc/testsuite/gcc.dg/tls/thr-init-1.c
    trunk/gcc/testsuite/gcc.dg/tls/thr-init-2.c
    trunk/gcc/testsuite/gcc.dg/torture/tls/
    trunk/gcc/testsuite/gcc.dg/torture/tls/thr-init-1.c
    trunk/gcc/testsuite/gcc.dg/torture/tls/thr-init-2.c
    trunk/gcc/testsuite/gcc.dg/torture/tls/tls-test.c
    trunk/gcc/testsuite/gcc.dg/torture/tls/tls.exp
    trunk/gcc/tree-emutls.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/Makefile.in
    trunk/gcc/config/i386/i386.c
    trunk/gcc/dwarf2out.c
    trunk/gcc/expr.c
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/f95-lang.c
    trunk/gcc/gimple-iterator.c
    trunk/gcc/output.h
    trunk/gcc/passes.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/g++.dg/gomp/clause-3.C
    trunk/gcc/testsuite/g++.dg/gomp/copyin-1.C
    trunk/gcc/testsuite/g++.dg/gomp/pr35244.C
    trunk/gcc/testsuite/g++.dg/gomp/sharing-1.C
    trunk/gcc/testsuite/g++.dg/gomp/tls-1.C
    trunk/gcc/testsuite/g++.dg/gomp/tls-2.C
    trunk/gcc/testsuite/g++.dg/gomp/tls-3.C
    trunk/gcc/testsuite/g++.dg/gomp/tls-4.C
    trunk/gcc/testsuite/g++.dg/tls/diag-1.C
    trunk/gcc/testsuite/g++.dg/tls/diag-2.C
    trunk/gcc/testsuite/g++.dg/tls/diag-3.C
    trunk/gcc/testsuite/g++.dg/tls/diag-4.C
    trunk/gcc/testsuite/g++.dg/tls/diag-5.C
    trunk/gcc/testsuite/g++.dg/tls/init-1.C
    trunk/gcc/testsuite/g++.dg/tls/init-2.C
    trunk/gcc/testsuite/g++.dg/tls/trivial.C
    trunk/gcc/testsuite/gcc.dg/gomp/appendix-a/a.22.1.c
    trunk/gcc/testsuite/gcc.dg/gomp/appendix-a/a.22.2.c
    trunk/gcc/testsuite/gcc.dg/gomp/appendix-a/a.24.1.c
    trunk/gcc/testsuite/gcc.dg/gomp/appendix-a/a.32.1.c
    trunk/gcc/testsuite/gcc.dg/gomp/appendix-a/a.33.1.c
    trunk/gcc/testsuite/gcc.dg/gomp/clause-1.c
    trunk/gcc/testsuite/gcc.dg/gomp/copyin-1.c
    trunk/gcc/testsuite/gcc.dg/gomp/pr35244.c
    trunk/gcc/testsuite/gcc.dg/gomp/sharing-1.c
    trunk/gcc/testsuite/gcc.dg/gomp/tls-1.c
    trunk/gcc/testsuite/gcc.dg/gomp/tls-2.c
    trunk/gcc/testsuite/gcc.dg/tls/opt-1.c
    trunk/gcc/testsuite/gcc.dg/tls/opt-13.c
    trunk/gcc/testsuite/gcc.dg/tls/opt-14.c
    trunk/gcc/testsuite/gcc.dg/tls/opt-15.c
    trunk/gcc/testsuite/gcc.dg/tls/opt-2.c
    trunk/gcc/testsuite/gcc.dg/tls/opt-3.c
    trunk/gcc/testsuite/gcc.dg/tls/opt-7.c
    trunk/gcc/testsuite/gfortran.dg/gomp/appendix-a/a.22.1.f90
    trunk/gcc/testsuite/gfortran.dg/gomp/appendix-a/a.22.4.f90
    trunk/gcc/testsuite/gfortran.dg/gomp/appendix-a/a.22.5.f90
    trunk/gcc/testsuite/gfortran.dg/gomp/appendix-a/a.22.6.f90
    trunk/gcc/testsuite/gfortran.dg/gomp/appendix-a/a.24.1.f90
    trunk/gcc/testsuite/gfortran.dg/gomp/appendix-a/a.32.1.f90
    trunk/gcc/testsuite/gfortran.dg/gomp/appendix-a/a.33.1.f90
    trunk/gcc/testsuite/gfortran.dg/gomp/crayptr2.f90
    trunk/gcc/testsuite/gfortran.dg/gomp/fixed-1.f
    trunk/gcc/testsuite/gfortran.dg/gomp/free-1.f90
    trunk/gcc/testsuite/gfortran.dg/gomp/omp_threadprivate1.f90
    trunk/gcc/testsuite/gfortran.dg/gomp/omp_threadprivate2.f90
    trunk/gcc/testsuite/gfortran.dg/gomp/reduction1.f90
    trunk/gcc/testsuite/gfortran.dg/gomp/sharing-1.f90
    trunk/gcc/toplev.c
    trunk/gcc/tree-pass.h
    trunk/gcc/tree.h
    trunk/gcc/varasm.c
    trunk/gcc/varpool.c


-- 


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

[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.

[rth at gcc dot gnu dot org]

-- 

rth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |rth at gcc dot gnu dot org
                   |dot org                     |
             Status|UNCONFIRMED                 |ASSIGNED
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2010-07-09 23:40:16
               date|                            |


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

[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.

[iains at gcc dot gnu dot org]

------- Comment #41 from iains at gcc dot gnu dot org  2010-07-03 16:45 -------
this should do it, asm problems solved.

http://gcc.gnu.org/ml/gcc-patches/2010-07/msg00262.html


-- 


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

[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.

[iains at gcc dot gnu dot org]

------- Comment #40 from iains at gcc dot gnu dot org  2010-06-04 18:45 -------
(In reply to comment #39)
> I confirm that the failures for libjava reported in comment #33 were due to
> some misconfiguration.
> With the patches in http://gcc.gnu.org/bugzilla/attachment.cgi?id=20762 and
> http://gcc.gnu.org/bugzilla/attachment.cgi?id=20822 , after a clean boostrap, I
> see the following new failures:
> 
> FAIL: g++.dg/tls/init-2.C (internal compiler error)
> FAIL: g++.dg/tls/init-2.C (test for excess errors)
> 
> FAIL: gcc.dg/tls/asm-1.c (internal compiler error)
> FAIL: gcc.dg/tls/asm-1.c  (test for errors, line 7)
> FAIL: gcc.dg/tls/asm-1.c (test for excess errors)
> 
> FAIL: obj-c++.dg/tls/init-2.mm -fgnu-runtime (internal compiler error)
> FAIL: obj-c++.dg/tls/init-2.mm -fnext-runtime (internal compiler error)

right, that's what I expect.

I think this :  gcc.dg/tls/asm-1.c is because gimplify_asm () doesn't consider
expansion of the parameter
(hopefully Honza could help with that).

I think that this : g++.dg/tls/init-2.C & obj-c++.dg/tls/init-2.mm - (which are
the same code)
 are down to two conflicting error responses from the C++ FE, -- there are two
error messages that disagree.

In other words, although these are regressions showing from the application of
the patch - I think they might be latent problems outside emutls.

I'll re-jig the patch to remove the ABI breakage and post over the next few
days.


-- 


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

[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.

[dominiq at lps dot ens dot fr]

------- Comment #39 from dominiq at lps dot ens dot fr  2010-06-04 18:25 -------
I confirm that the failures for libjava reported in comment #33 were due to
some misconfiguration.
With the patches in http://gcc.gnu.org/bugzilla/attachment.cgi?id=20762 and
http://gcc.gnu.org/bugzilla/attachment.cgi?id=20822 , after a clean boostrap, I
see the following new failures:

FAIL: g++.dg/tls/init-2.C (internal compiler error)
FAIL: g++.dg/tls/init-2.C (test for excess errors)

FAIL: gcc.dg/tls/asm-1.c (internal compiler error)
FAIL: gcc.dg/tls/asm-1.c  (test for errors, line 7)
FAIL: gcc.dg/tls/asm-1.c (test for excess errors)

FAIL: obj-c++.dg/tls/init-2.mm -fgnu-runtime (internal compiler error)
FAIL: obj-c++.dg/tls/init-2.mm -fnext-runtime (internal compiler error)


-- 


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

[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.

[iains at gcc dot gnu dot org]

------- Comment #38 from iains at gcc dot gnu dot org  2010-06-03 23:45 -------
(In reply to comment #37)
> (In reply to comment #35)
> > Note the failures occur only with -m64, not with -m32.
> 
> This may due to a misconfiguration of libjava similar to pr43170. I am
> bootstrapping with the latest patch and I'll redo the testing tomorrow.

i686-darwin9 + comment #26 + PR43170 comment #72 
showed just one failure at m64  - FAIL: PR16923 run.

                === libjava Summary ===

# of expected passes            5147
# of unexpected failures        1
# of untested testcases         1

---
x86_64-darwin10 bootstrapped (same patches) and runs all tls and libgomp tests
as expected.  (and nm shows that libgomp is using emutls).

[I haven't bootstrapped java on x86_64-darwin10, so that test result is still
awaited].


-- 


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

[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.

[dominiq at lps dot ens dot fr]

------- Comment #37 from dominiq at lps dot ens dot fr  2010-06-03 20:57 -------
(In reply to comment #35)
> Note the failures occur only with -m64, not with -m32.

This may due to a misconfiguration of libjava similar to pr43170. I am
bootstrapping with the latest patch and I'll redo the testing tomorrow.


-- 


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

[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.

[iains at gcc dot gnu dot org]

------- Comment #36 from iains at gcc dot gnu dot org  2010-06-03 16:08 -------
(In reply to comment #35)
> Extracted from x86_64-apple-darwin10.3.0/libjava/testsuite/libjava.log:
> 
> ...
> set_ld_library_path_env_vars:
> ld_library_path=.:/opt/gcc/build_w/x86_64-apple-darwin10.3.0/./libjava/.libs
> invoke: /opt/gcc/build_w/x86_64-apple-darwin10.3.0/./libjava/gij -jar
> /opt/gcc/work/libjava/testsuite/libjava.jar/TestClosureGC.jar
> Setting LD_LIBRARY_PATH to
> .:/opt/gcc/build_w/x86_64-apple-darwin10.3.0/./libjava/.libs:.:/opt/gcc/build_w/x86_64-apple-darwin10.3.0/./libjava/.libs
> Exception in thread "main" java.lang.NullPointerException
>    at TestClosureGC.main(TestClosureGC.java:108)
> FAIL: /opt/gcc/work/libjava/testsuite/libjava.jar/TestClosureGC.jar execution -
> gij test
> UNTESTED: /opt/gcc/work/libjava/testsuite/libjava.jar/TestClosureGC.jar output
> - gij test
> ...
> 
> Note the failures occur only with -m64, not with -m32.

OK, libjava uses __thread so I need to investigate what's happening there;

However, java is not using the emutls facility from its FE (AFAICT).


-- 


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

[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.

[dominiq at lps dot ens dot fr]

------- Comment #35 from dominiq at lps dot ens dot fr  2010-06-03 15:21 -------
Extracted from x86_64-apple-darwin10.3.0/libjava/testsuite/libjava.log:

...
set_ld_library_path_env_vars:
ld_library_path=.:/opt/gcc/build_w/x86_64-apple-darwin10.3.0/./libjava/.libs
invoke: /opt/gcc/build_w/x86_64-apple-darwin10.3.0/./libjava/gij -jar
/opt/gcc/work/libjava/testsuite/libjava.jar/TestClosureGC.jar
Setting LD_LIBRARY_PATH to
.:/opt/gcc/build_w/x86_64-apple-darwin10.3.0/./libjava/.libs:.:/opt/gcc/build_w/x86_64-apple-darwin10.3.0/./libjava/.libs
Exception in thread "main" java.lang.NullPointerException
   at TestClosureGC.main(TestClosureGC.java:108)
FAIL: /opt/gcc/work/libjava/testsuite/libjava.jar/TestClosureGC.jar execution -
gij test
UNTESTED: /opt/gcc/work/libjava/testsuite/libjava.jar/TestClosureGC.jar output
- gij test
...

Note the failures occur only with -m64, not with -m32.


-- 


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

[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.

[iains at gcc dot gnu dot org]

------- Comment #34 from iains at gcc dot gnu dot org  2010-06-03 15:03 -------
(In reply to comment #33)
> On x86_64-apple-darwin10.3.0 the patch in comment #26 applied on top of r160219
> cause 
> 
>                 === libjava Summary for unix/-m64 ===
> 
> # of expected passes            2459
> # of unexpected failures        62
> # of untested testcases         55

hm.  grep of:
 tls, THREAD_LOCAL_P,  TLS_MODEL and __thread in gcc/java/* returns "".
(I had done that before, but just checked again).


-- 


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

[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.

[dominiq at lps dot ens dot fr]

------- Comment #33 from dominiq at lps dot ens dot fr  2010-06-03 14:52 -------
On x86_64-apple-darwin10.3.0 the patch in comment #26 applied on top of r160219
cause 

                === libjava Summary for unix/-m64 ===

# of expected passes            2459
# of unexpected failures        62
# of untested testcases         55


-- 


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

[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.

[iains at gcc dot gnu dot org]

------- Comment #32 from iains at gcc dot gnu dot org  2010-06-03 09:21 -------
(In reply to comment #31)
> The latest proposed patch triggers one additional g++ tls failure...
> 
> FAIL: g++.dg/tls/init-2.C (test for excess errors)

this test is not enabled for emutls at present;
yes, I know it fails - but - if you look at the error output from g++, you will
see that there are two confusing and contradictory error messages - so I
suspect that the FE is trying to build a constructor for something that has
been declared an error...

Still, this should be on the TODO ;-)


-- 


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

[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.

[howarth at nitro dot med dot uc dot edu]

------- Comment #31 from howarth at nitro dot med dot uc dot edu  2010-06-03 01:10 -------
The latest proposed patch triggers one additional g++ tls failure...

FAIL: g++.dg/tls/init-2.C (test for excess errors)

with http://gcc.gnu.org/ml/gcc-patches/2010-05/txt00053.txt...

Executing on host:
/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/testsuite/g++/../../g++
-B/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/testsuite/g++/../../
/sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20100602/gcc/testsuite/g++.dg/tls/init-2.C
 -nostdinc++
-I/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/x86_64-apple-darwin10.4.0/libstdc++-v3/include/x86_64-apple-darwin10.4.0
-I/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/x86_64-apple-darwin10.4.0/libstdc++-v3/include
-I/sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20100602/libstdc++-v3/libsupc++
-I/sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20100602/libstdc++-v3/include/backward
-I/sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20100602/libstdc++-v3/testsuite/util
-fmessage-length=0   -ansi -pedantic-errors -Wno-long-long  -S  -o init-2.s   
(timeout = 300)
/sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20100602/gcc/testsuite/g++.dg/tls/init-2.C:5:20:
error: 'p' is thread-local and so cannot be dynamically initialized
/sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20100602/gcc/testsuite/g++.dg/tls/init-2.C:8:20:
error: 'j' is thread-local and so cannot be dynamically initialized
/sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20100602/gcc/testsuite/g++.dg/tls/init-2.C:14:12:
error: 's' cannot be thread-local because it has non-trivial type 'S'
/sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20100602/gcc/testsuite/g++.dg/tls/init-2.C:14:12:
error: 's' is thread-local and so cannot be dynamically initialized
/sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20100602/gcc/testsuite/g++.dg/tls/init-2.C:14:
confused by earlier errors, bailing out
compiler exited with status 1
output is:
/sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20100602/gcc/testsuite/g++.dg/tls/init-2.C:5:20:
error: 'p' is thread-local and so cannot be dynamically initialized
/sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20100602/gcc/testsuite/g++.dg/tls/init-2.C:8:20:
error: 'j' is thread-local and so cannot be dynamically initialized
/sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20100602/gcc/testsuite/g++.dg/tls/init-2.C:14:12:
error: 's' cannot be thread-local because it has non-trivial type 'S'
/sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20100602/gcc/testsuite/g++.dg/tls/init-2.C:14:12:
error: 's' is thread-local and so cannot be dynamically initialized
/sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20100602/gcc/testsuite/g++.dg/tls/init-2.C:14:
confused by earlier errors, bailing out

PASS: g++.dg/tls/init-2.C  (test for errors, line 5)
PASS: g++.dg/tls/init-2.C  (test for errors, line 8)
PASS: g++.dg/tls/init-2.C  (test for errors, line 14)
FAIL: g++.dg/tls/init-2.C (test for excess errors)
Excess errors:
/sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20100602/gcc/testsuite/g++.dg/tls/init-2.C:14:
confused by earlier errors, bailing out


-- 


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

[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.

[iains at gcc dot gnu dot org]

------- Comment #30 from iains at gcc dot gnu dot org  2010-06-02 20:41 -------
(In reply to comment #29)
> I don't see that as justification for breaking the ABI.

no problem - I'll revert that part. 

I had thought that since these vars could get hit very hard in parallel code,
the 0 offset might be worth something.


-- 


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

[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.

[jakub at gcc dot gnu dot org]

------- Comment #29 from jakub at gcc dot gnu dot org  2010-06-02 20:35 -------
I don't see that as justification for breaking the ABI.


-- 


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

[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.

[iains at gcc dot gnu dot org]

------- Comment #28 from iains at gcc dot gnu dot org  2010-05-27 22:52 -------
(In reply to comment #27)
> Can you explain the struct __emutls_object change?  That is an ABI break (and I
> don't see anywhere any rationale for that).

I did it for two reasons; 
1/ to prove that I'd got a handle on everywhere it was being used.
2/ to put the pointer at 0 offset in the structure.

However, it's easily reversed if there is felt to be no benefit from 2.

I also moved a chunk of code in varasm to collect the emutls code together -
again that is not important to the fix.


-- 


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

[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.

[jakub at gcc dot gnu dot org]

------- Comment #27 from jakub at gcc dot gnu dot org  2010-05-27 22:02 -------
Can you explain the struct __emutls_object change?  That is an ABI break (and I
don't see anywhere any rationale for that).


-- 


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

[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.

[iains at gcc dot gnu dot org]

------- Comment #26 from iains at gcc dot gnu dot org  2010-05-27 20:11 -------
Created an attachment (id=20762)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20762&action=view)
candidate fix that handles aliases as well.

PR44276 revealed that I wasn't handling alias cases.

The new attachment deal with this and is tested on
 i686-apple-darwin, cris-elf.

TODO; 
  gimplification of asm statements that include emuTLS vars.
  tree-profile.c


-- 

iains at gcc dot gnu dot org changed:

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


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

[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.

[iains at gcc dot gnu dot org]

------- Comment #25 from iains at gcc dot gnu dot org  2010-05-25 09:38 -------
#24 works for me also on powerpc-apple-darwin9 and powerpc64-apple-darwin9.


-- 


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

[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.

[iains at gcc dot gnu dot org]

------- Comment #24 from iains at gcc dot gnu dot org  2010-05-24 20:11 -------
Created an attachment (id=20738)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20738&action=view)
candidate solution (with all the files)

and now with all the changed files ...


-- 

iains at gcc dot gnu dot org changed:

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


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

[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.

[iains at gcc dot gnu dot org]

------- Comment #23 from iains at gcc dot gnu dot org  2010-05-24 17:27 -------
Created an attachment (id=20736)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20736&action=view)
candidate solution 

OK, so comment #22 is the work-around ... 

.. here is the current version of the "proper" solution - that makes the emutls
vars recognized by OMP and LTO.

This works for me for c, c++,Objc, ObjC++ and Fortran (i686 and x86_64 darwin,
[ powerpc as well but not recently bootstrapped]) with one regression:

gcc.dg/tls/asm-1.c  -- would be good if someone more gimplifier experience
could look at gimplify_asm () and see where there is a wrong assumption about
arguments...

There is a "latent" regression in c++ (if we enable all the tls_native tests
applicable) - this is a case where there are two conflicting error messages -
and I think the FE has got confused about whether the var is __thread or not
and tries to create a static constructor for a failed case .. but not 100% sure
about that.

====

TODO:  The expansion of gimplification in tree-profile.c (not a regression
currently, but one waiting to happen).

====

This is ready to kick around a bit -- could other affected targets test/give
opinions etc?

I guess we should get comments on whether this is too invasive...
...  although, if that's felt to be the case I'd like suggestions as to where
else to hook in.. :-)


-- 

iains at gcc dot gnu dot org changed:

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


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

[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.

[iains at gcc dot gnu dot org]

------- Comment #22 from iains at gcc dot gnu dot org  2010-05-24 14:36 -------
Subject: Bug 44132

Author: iains
Date: Mon May 24 14:36:32 2010
New Revision: 159781

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159781
Log:
2010-05-24  Iain Sandoe  <iains@gcc.gnu.org>

        PR target/44132
        PR middle-end/43602
        * varasm.c (get_emutls_init_templ_addr): Copy DECL_PRESERVE_P,
        DECL_VISIBILITY_SPECIFIED.
        (emutls_decl): Set DECL_PRESERVE_P and copy
        DECL_VISIBILITY_SPECIFIED, DECL_RESTRICTED_P.
        (emutls_finalize_control_var): New callback.
        (emutls_finish): Finalize emutls control variables.
        * toplev.c (compile_file): Move the call to emutls_finish () 
        before varpool_assemble_pending_decls ().


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/toplev.c
    trunk/gcc/varasm.c


-- 


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

[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.

[iains at gcc dot gnu dot org]

------- Comment #21 from iains at gcc dot gnu dot org  2010-05-19 14:48 -------
Created an attachment (id=20701)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20701&action=view)
latest.. 

this is mostly there ... might be worth trying on other platforms for feedback.

without the catch-net of expr.c (which covered up several things.. )

When stuff works here it seems to work across the board now (including lto,
whopr).

three issues:
1/ Finalization of emutls control vars.
2/ Failure to emit constructor for uninitialized control vars.
3/ Small buglet in emutls.

strategy for 
(1)
 a) finalization of the control vars is cascaded from finalization of the
user-land vars in varpool.c 
 b) a mop-up pass is carried out in emutls_final() - this is needed to pick up
vars introduced by late passes (in particular by OMP).

 c) The initializer for init vars is applied and decl-finalized as soon as it
is presented (we keep a mark to notice if the user tries to re-init).

 d) I've reorganized the code in varpool_finalize_decl () to ensure that
varpool_enqueue_needed_node () is not done until after all the checks have been
carried out for 'needed'.
 e) Removed some redundant calls to varpool_assemble_pending_decls () from
varpool_finalize_decl ().

2.  
 (a) some code re-organization in varasm.c to put all the emutls stuff
together. 
 (b) re-wrote the emutls structure to put the pointer at the start.
 (c) all tls control vars are static and they all need to be constructed -
(FWIW DECL_COMMON() was never set anyway)/

3. I put some comments into emutls.c since I had to figure it out ... and a
minor bug that would hit after you reached 32 emutls vars.

----
I'd welcome feedback on the approach(es) and whether it helps on other EMUTLS
platforms.
----

What is **NOT** fixed:
A>> there is still some leakage in OMP (some interaction with threadprivate)  I
will carry on looking at that ... 

B>> PR43602 -- the tree-profile pass generates gimple directly without
considering that it might need to be further gimplifed... 
C>> PR44140 -- although it shows up in a tls test is not realted to these
issues.


-- 

iains at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #20688|0                           |1
        is obsolete|                            |
  Attachment #20693|0                           |1
        is obsolete|                            |


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

[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.

[ro at gcc dot gnu dot org]

------- Comment #20 from ro at gcc dot gnu dot org  2010-05-19 10:39 -------
This seems to be the same problem that breaks Solaris 8/9 SPARC bootstrap with
Sun
as: several libjava tools fail to link:

Undefined                       first referenced
 symbol                             in file
__emutls_v._ZL12method_cache        ./.libs/libgcj.so
ld: fatal: Symbol referencing errors. No output written to .libs/jv-convert
collect2: ld returned 1 exit status
make[3]: *** [jv-convert] Error 1


-- 

ro at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ro at gcc dot gnu dot org


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

[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.

[dominiq at lps dot ens dot fr]

------- Comment #19 from dominiq at lps dot ens dot fr  2010-05-18 16:55 -------
This PR may have an overlap with pr44139.


-- 


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

[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.

[iains at gcc dot gnu dot org]

------- Comment #18 from iains at gcc dot gnu dot org  2010-05-18 15:55 -------
(In reply to comment #17)
> Created an attachment (id=20693)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20693&action=view) [edit]
> latest version
> 
> a few more tweaks.
> with this emutls is working for lto/whopr

actually, with that patch,  lto is clean and whopr has reduced fails (still
some symbols not getting through).

> OMP is still broken

hmm. it's not quite that -- the working libgomp was *not* using emutls (but
standard pthread calls).

So the configury machinery is detecting that tls works on with the current
patch :)
-- it just doesn't work well enough ...  ;)


-- 


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

[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.

[iains at gcc dot gnu dot org]

------- Comment #17 from iains at gcc dot gnu dot org  2010-05-18 09:09 -------
Created an attachment (id=20693)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20693&action=view)
latest version

a few more tweaks.
with this emutls is working for lto/whopr
OMP is still broken and so will be tree-prof if it uses TLS.


-- 


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

[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.

[iains at gcc dot gnu dot org]

------- Comment #16 from iains at gcc dot gnu dot org  2010-05-18 01:40 -------
the patch below helps...

I also suspect we might have to check for emutls vars twice - because they can
be introduced by profiling code 

just for the sake of a trial - I've put the emutls_final into toplev.c twice:
-- before   lang_hooks.decls.final_write_globals ();
-- and before ..   varpool_assemble_pending_decls ();

with all of that (but output disabled from expr.c) 
torture/tls/thr-init-1.c fails lto/whopr
BUT torture/tls/thr-init-2.c passes :-)

and libgomp looks *much* better...

still there must be other places that output is being produced...

===

Index: gcc/varpool.c
===================================================================
--- gcc/varpool.c       (revision 159523)
+++ gcc/varpool.c       (working copy)
@@ -297,6 +297,14 @@ varpool_mark_needed_node (struct varpool_node *nod
       && !TREE_ASM_WRITTEN (node->decl))
     varpool_enqueue_needed_node (node);
   node->needed = 1;
+  /* If we need the var, and it's an emulated TLS entity, that
+     means we need the control var.  */
+  if (!targetm.have_tls && DECL_THREAD_LOCAL_P (node->decl))
+    {
+      struct varpool_node *cv_node;
+      cv_node = varpool_node (emutls_decl (node->decl)) ;
+      varpool_mark_needed_node (cv_node);
+    }
 }

 /* Reset the queue of needed nodes.  */
@@ -366,11 +374,7 @@ varpool_finalize_decl (tree decl)
      or local (in C, has internal linkage).  So do nothing more
      if this function has already run.  */
   if (node->finalized)
-    {
-      if (cgraph_global_info_ready)
-       varpool_assemble_pending_decls ();
       return;
-    }
   if (node->needed)
     varpool_enqueue_needed_node (node);
   node->finalized = true;
@@ -384,8 +388,6 @@ varpool_finalize_decl (tree decl)
      there.  */
   else if (TREE_PUBLIC (decl) && !DECL_COMDAT (decl) && !DECL_EXTERNAL (decl))
     varpool_mark_needed_node (node);
-  if (cgraph_global_info_ready)
-    varpool_assemble_pending_decls ();
 }

 /* Return variable availability.  See cgraph.h for description of individual


-- 


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

[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.

[iains at gcc dot gnu dot org]

------- Comment #15 from iains at gcc dot gnu dot org  2010-05-17 20:31 -------
the libgomp fails with comment #14 are pretty much:
/i686-apple-darwin9/./libgomp/.libs:/Volumes/ScratchCS/gcc-4-6-trunk-build/gcc
atomic-4.exe(94763) malloc: *** error for object 0x800180: pointer being
reallocated was not allocated
*** set a breakpoint in malloc_error_break to debug


-- 


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

[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.

[iains at gcc dot gnu dot org]

------- Comment #14 from iains at gcc dot gnu dot org  2010-05-17 20:22 -------
Created an attachment (id=20688)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20688&action=view)
Work-In-Progress...

here is a modification of comment #7 which gets us a bit further .. but I'm a
bit stumped in some areas.
There are a couple of extra test-cases that I'm using locally to help testing
(probably not for a final patch).

===
A. this checks for emutls vars in VAR/PARAM cases in gimplify.
B. This moves the creation of the init template out of assemble_variable into
emutls_decl () - as soon as we see a DECL_INITIAL we do it .. and then we mark
the original decl with DECL_INITIAL=error_mark so that we still get a parse
error if the user tries to init twice.
C. emutls_final () carries out a pass through the emutls control vars
finalizing them if they are not already done.
D. the substitution of the control var is removed from gcc/expr.c.

Mostly - this is working for tls.exp=* 
unfortunately -lto/-whopr are still killing the control vars (even @ O0)

====
Problems :

1/ It doesn't work with the race condition patch applied to tree-profile.c --
this is because tree-profile is emitting gimple directly and assuming that it
doesn't need gimplification (and I've not been able to figure out how to fix
that yet).
2/ It breaks libgomp quite a bit ... I'm guessing that there's another spot in
gimplify.c that we need to apply the substitution but - can't see it yet .. ;)

anyway ... Honza .. I'm sure you will see the solutions 10^6 times quicker than
me...

*** this is experimental *** (some way from a complete solution)


-- 


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

[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.

[iains at gcc dot gnu dot org]

------- Comment #13 from iains at gcc dot gnu dot org  2010-05-15 15:40 -------
see: http://gcc.gnu.org/ml/gcc-patches/2010-05/msg01119.html for a workaround


-- 


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

[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.

[hubicka at ucw dot cz]

------- Comment #12 from hubicka at ucw dot cz  2010-05-15 13:49 -------
Subject: Re:  [4.6 Regression] emutls is broken under a
        range of circumstances.

> I guess, otherwise, we have to intercept every circumstance where a __thread
> var might be used .. and interpose the exchange.
Hmm, does combination of PRESERVE hack and the gimplifier change gets the
testsuite
clean and both LTO/WHOR working?
You can construct a testcase where you have two source units both having thread
local
variables with uses all intlined into main().  This is case where I think the
DECL_PRESERVE hack should fall appart.


-- 


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

[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.

[hubicka at ucw dot cz]

------- Comment #11 from hubicka at ucw dot cz  2010-05-15 13:48 -------
Subject: Re:  [4.6 Regression] emutls is broken under a
        range of circumstances.

> I'd rather go with the DECL_PRESERVE_P hack for now.
Problem with this is that emultls is still broken with LTO.  As soon as we
merge multiple emultls vars from multiple units, we will screw up at expansion
time.  


-- 


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

[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.

[iains at gcc dot gnu dot org]

------- Comment #10 from iains at gcc dot gnu dot org  2010-05-15 11:57 -------
hmm - that certainly looks simpler...

I guess, otherwise, we have to intercept every circumstance where a __thread
var might be used .. and interpose the exchange.


-- 


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

[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.

[rguenth at gcc dot gnu dot org]

------- Comment #9 from rguenth at gcc dot gnu dot org  2010-05-15 11:32 -------
I'd rather go with the DECL_PRESERVE_P hack for now.


-- 


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

[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.

[iains at gcc dot gnu dot org]

------- Comment #8 from iains at gcc dot gnu dot org  2010-05-15 11:24 -------
(In reply to comment #7)
> Subject: Re:  [4.6 Regression] emutls is broken under a
>         range of circumstances.

> Correct fix is to lower emultls earlier so both ipa-ref and LTO understands it.
> This might be bit too early, but I think we can stick it into gimplifier as
> follows

works except where the var is initialized... 
where an init var is present, the compiler appears to be emitting native TLS
code .. :-(

so I guess there's another arm that needs to be intercepted .. 


-- 


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

[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.

[hubicka at ucw dot cz]

------- Comment #7 from hubicka at ucw dot cz  2010-05-15 09:35 -------
Subject: Re:  [4.6 Regression] emutls is broken under a
        range of circumstances.

Hi,
we can either go with DECL_PRESERVE that is kind of hack but makes situation no
worse.
Correct fix is to lower emultls earlier so both ipa-ref and LTO understands it.
This might be bit too early, but I think we can stick it into gimplifier as
follows

Index: expr.c
===================================================================
--- expr.c      (revision 159421)
+++ expr.c      (working copy)
@@ -6759,19 +6759,6 @@ highest_pow2_factor_for_target (const_tr
   return MAX (factor, talign);
 }

-/* Return &VAR expression for emulated thread local VAR.  */
-
-static tree
-emutls_var_address (tree var)
-{
-  tree emuvar = emutls_decl (var);
-  tree fn = built_in_decls [BUILT_IN_EMUTLS_GET_ADDRESS];
-  tree arg = build_fold_addr_expr_with_type (emuvar, ptr_type_node);
-  tree arglist = build_tree_list (NULL_TREE, arg);
-  tree call = build_function_call_expr (UNKNOWN_LOCATION, fn, arglist);
-  return fold_convert (build_pointer_type (TREE_TYPE (var)), call);
-}
-\f

 /* Subroutine of expand_expr.  Expand the two operands of a binary
    expression EXP0 and EXP1 placing the results in OP0 and OP1.
@@ -6866,15 +6853,6 @@ expand_expr_addr_expr_1 (tree exp, rtx t
       break;

     case VAR_DECL:
-      /* TLS emulation hook - replace __thread VAR's &VAR with
-        __emutls_get_address (&_emutls.VAR).  */
-      if (! targetm.have_tls
-         && TREE_CODE (exp) == VAR_DECL
-         && DECL_THREAD_LOCAL_P (exp))
-       {
-         exp = emutls_var_address (exp);
-         return expand_expr (exp, target, tmode, modifier);
-       }
       /* Fall through.  */

     default:
@@ -8406,16 +8384,6 @@ expand_expr_real_1 (tree exp, rtx target
          && (TREE_STATIC (exp) || DECL_EXTERNAL (exp)))
        layout_decl (exp, 0);

-      /* TLS emulation hook - replace __thread vars with
-        *__emutls_get_address (&_emutls.var).  */
-      if (! targetm.have_tls
-         && TREE_CODE (exp) == VAR_DECL
-         && DECL_THREAD_LOCAL_P (exp))
-       {
-         exp = build_fold_indirect_ref_loc (loc, emutls_var_address (exp));
-         return expand_expr_real_1 (exp, target, tmode, modifier, NULL);
-       }
-
       /* ... fall through ...  */

     case FUNCTION_DECL:
Index: gimplify.c
===================================================================
--- gimplify.c  (revision 159421)
+++ gimplify.c  (working copy)
@@ -1309,6 +1309,18 @@ gimplify_vla_decl (tree decl, gimple_seq
   gimplify_ctxp->save_stack = true;
 }

+/* Return &VAR expression for emulated thread local VAR.  */
+
+static tree
+emutls_var_address (tree var)
+{
+  tree emuvar = emutls_decl (var);
+  tree fn = built_in_decls [BUILT_IN_EMUTLS_GET_ADDRESS];
+  tree arg = build_fold_addr_expr_with_type (emuvar, ptr_type_node);
+  tree arglist = build_tree_list (NULL_TREE, arg);
+  tree call = build_function_call_expr (UNKNOWN_LOCATION, fn, arglist);
+  return fold_convert (build_pointer_type (TREE_TYPE (var)), call);
+}

 /* Gimplifies a DECL_EXPR node *STMT_P by making any necessary allocation
    and initialization explicit.  */
@@ -1320,6 +1332,15 @@ gimplify_decl_expr (tree *stmt_p, gimple
   tree decl = DECL_EXPR_DECL (stmt);

   *stmt_p = NULL_TREE;
+  /* TLS emulation hook - replace __thread VAR's &VAR with
+     __emutls_get_address (&_emutls.VAR).  */
+  if (! targetm.have_tls
+      && TREE_CODE (decl) == VAR_DECL
+      && DECL_THREAD_LOCAL_P (decl))
+    {
+      *stmt_p = build_fold_indirect_ref (emutls_var_address (decl));
+      return GS_OK;
+    }

   if (TREE_TYPE (decl) == error_mark_node)
     return GS_ERROR;


-- 


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

[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.

[iains at gcc dot gnu dot org]

------- Comment #6 from iains at gcc dot gnu dot org  2010-05-15 09:25 -------
(In reply to comment #5)

> Index: gcc/varasm.c
> ===================================================================
> --- gcc/varasm.c        (revision 159429)
> +++ gcc/varasm.c        (working copy)
> @@ -386,6 +386,7 @@ emutls_decl (tree decl)
>        DECL_TLS_MODEL (to) = TLS_MODEL_EMULATED;
>        DECL_ARTIFICIAL (to) = 1;
>        DECL_IGNORED_P (to) = 1;
> +      DECL_PRESERVE_P (to) = 1;
>        TREE_READONLY (to) = 0;
>        SET_DECL_ASSEMBLER_NAME (to, DECL_NAME (to));
>        if (DECL_ONE_ONLY (decl))
> 
> looks good so far .. I'll have to wait for the bootstrap on x86_64 to
> succeed/fail to try it there too (PR44146
> 

with this the FE problems (less LTO) are resolved and libgomp is restored less
three C++ CTOR-related tests (ctor-5, ctor-8 and ctor-9).


-- 


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

[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.

[iains at gcc dot gnu dot org]

------- Comment #5 from iains at gcc dot gnu dot org  2010-05-15 08:59 -------
(In reply to comment #4)
> Subject: Re:  [4.6 Regression] emutls is broken under a
>         range of circumstances.
> 
> The problem is because emultls is handling declarations in a way so references
> are not visible to
> middle end.  I guess we need to put DECL_PRESERVE at the emultls variable so it
> stays innert.

Index: gcc/varasm.c
===================================================================
--- gcc/varasm.c        (revision 159429)
+++ gcc/varasm.c        (working copy)
@@ -386,6 +386,7 @@ emutls_decl (tree decl)
       DECL_TLS_MODEL (to) = TLS_MODEL_EMULATED;
       DECL_ARTIFICIAL (to) = 1;
       DECL_IGNORED_P (to) = 1;
+      DECL_PRESERVE_P (to) = 1;
       TREE_READONLY (to) = 0;
       SET_DECL_ASSEMBLER_NAME (to, DECL_NAME (to));
       if (DECL_ONE_ONLY (decl))

looks good so far .. I'll have to wait for the bootstrap on x86_64 to
succeed/fail to try it there too (PR44146


-- 


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

[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.

[hubicka at ucw dot cz]

------- Comment #4 from hubicka at ucw dot cz  2010-05-15 08:39 -------
Subject: Re:  [4.6 Regression] emutls is broken under a
        range of circumstances.

The problem is because emultls is handling declarations in a way so references
are not visible to
middle end.  I guess we need to put DECL_PRESERVE at the emultls variable so it
stays innert.

Honza


-- 


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

[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.

[iains at gcc dot gnu dot org]

------- Comment #3 from iains at gcc dot gnu dot org  2010-05-15 08:29 -------
note fails are for O > 0


-- 


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

[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.

[iains at gcc dot gnu dot org]

------- Comment #2 from iains at gcc dot gnu dot org  2010-05-15 08:25 -------
as of 159429 - m32 seems to be fixed (and m64 improved): 

                === libgomp Summary for unix/-m32 ===

# of expected passes            2490
# of unsupported tests          2
                === libgomp Summary for unix/-m64 ===

# of expected passes            2386
# of unexpected failures        52
# of unsupported tests          2

-fails are all in libgomp.c++/ and libgomp.fortran/ (although that might be
co-incidence).
----

the fails seem to occur when an emutls variable is declared static.

same situation applies to FE tls tests (m32 is OK modulo LTO issues, m64 has
fails).


-- 


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

[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.6.0


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

[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.

[iains at gcc dot gnu dot org]

------- Comment #1 from iains at gcc dot gnu dot org  2010-05-14 08:17 -------
this was caused by r159370, 72 or 72.
(CC ing Jan Hubika).

in case it's relevant, the emutls control vars are not finalized .
I have a patch to do this
(http://gcc.gnu.org/ml/gcc-patches/2010-05/msg00824.html) ...
...  however, it doesn't solve this problem as applied there.

I mention because the symptoms are similar -- variables 'optimized away'.


-- 

iains at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hubicka at gcc dot gnu dot
                   |                            |org


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