[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44132 --- Comment #44 from Andrew Pinski --- *** 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.
--- 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=gccview=revrev=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.
--- 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 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|-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.
--- 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.
--- 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.
--- 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.
--- 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.
--- 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 passes2459 # of unexpected failures62 # 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.
--- 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 passes2459 # of unexpected failures62 # 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.
--- 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.
--- 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.
--- 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.
--- 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 passes5147 # of unexpected failures1 # 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.
--- 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.
--- 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.
--- 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.
--- 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=20762action=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.
--- 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.
--- 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.
--- 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.
--- 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=gccview=revrev=159781 Log: 2010-05-24 Iain Sandoe ia...@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.
--- 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=20736action=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.
--- 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=20738action=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.
--- 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.
--- 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=20701action=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.
--- 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=20693action=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.
--- 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=20693action=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.
--- 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.
--- 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=20688action=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.
--- 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.
--- 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.
--- 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 passes2490 # of unsupported tests 2 === libgomp Summary for unix/-m64 === # of expected passes2386 # of unexpected failures52 # 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.
--- 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.
--- 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.
--- 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.
--- 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.
--- 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);
-}
-
/* 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.
--- 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.
--- 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.
--- 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.
--- 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.
--- 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.
--- 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.
--- 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
[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.
-- 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
