--- Comment #23 from davek at gcc dot gnu dot org 2009-09-16 10:19 ---
Created an attachment (id=18595)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18595action=view)
simplified fix
After discussion on the -patches list, it seemed sensible to try preserving the
precise value of
--- Comment #24 from jakub at gcc dot gnu dot org 2009-09-16 10:37 ---
As the __emul* decls are using TLS_MODEL_EMULATED, this patch might make even
their SYMBOL_REFs start using that TLS model. But, unlike the user vars, these
occur normally in the instruction stream, so I wonder if
--- Comment #25 from davek at gcc dot gnu dot org 2009-09-16 10:51 ---
(In reply to comment #24)
As the __emul* decls are using TLS_MODEL_EMULATED, this patch might make even
their SYMBOL_REFs start using that TLS model. But, unlike the user vars,
these
occur normally in the
--- Comment #26 from davek at gcc dot gnu dot org 2009-09-16 10:54 ---
Created an attachment (id=18596)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18596action=view)
YA respin
don't copy tls model into rtl flags for TLS_MODEL_EMULATED, only other values.
--
davek at gcc dot
--- Comment #3 from davek at gcc dot gnu dot org 2009-09-15 12:47 ---
This bug is also present on i686-pc-cygwin at r.151703, so given Jie's
diagnosis in comment 2, let's switch the component from 'target' to 'debug'.
libtool: link: /gnu/gcc/obj.libstdc.enabled/./gcc/xgcc
--- Comment #4 from davek at gcc dot gnu dot org 2009-09-15 12:52 ---
(In reply to comment #2)
I think it's the same issue for PR41357.
*This* is PR41357; you must mean PR41308. Yes, I think so, I'll mark it as a
dup of this one.
--
--- Comment #5 from davek at gcc dot gnu dot org 2009-09-15 12:52 ---
*** Bug 41308 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41357
--- Comment #6 from davek at gcc dot gnu dot org 2009-09-15 13:29 ---
(In reply to comment #1)
The cause is that DW_TAG_variable references gomp_tls_data instead of
___emutls_v.gomp_tls_data.
Here's an example:
1f51: Abbrev Number: 49 (DW_TAG_variable)
f52 DW_AT_name
--- Comment #7 from davek at gcc dot gnu dot org 2009-09-15 13:40 ---
This looks a little tricky.
Knowledge of the __emutls_v. prefix is entirely private to varasm.c. The
actual prefixed object itself escapes publicly with that name, but only
varasm.c knows that subsequent references
--- Comment #8 from davek at gcc dot gnu dot org 2009-09-15 14:07 ---
(In reply to comment #6)
(In reply to comment #1)
The cause is that DW_TAG_variable references gomp_tls_data instead of
___emutls_v.gomp_tls_data.
Here's an example:
No, that's not it, that's not it at
--- Comment #9 from jzhang918 at gmail dot com 2009-09-15 14:21 ---
(In reply to comment #8)
(In reply to comment #6)
(In reply to comment #1)
The cause is that DW_TAG_variable references gomp_tls_data instead of
___emutls_v.gomp_tls_data.
Here's an example:
No,
--- Comment #10 from davek at gcc dot gnu dot org 2009-09-15 14:24 ---
(In reply to comment #9)
(In reply to comment #8)
(In reply to comment #6)
(In reply to comment #1)
The cause is that DW_TAG_variable references gomp_tls_data instead of
___emutls_v.gomp_tls_data.
--- Comment #11 from davek at gcc dot gnu dot org 2009-09-15 14:53 ---
The bogus const info is added in at the end of this call chain, when generating
the var die:
#0 0x004d0679 in add_const_value_attribute (die=0x7fcbd660, rtl=0x7fd20270)
at /gnu/gcc/gcc/gcc/tree.h:182
#1
--- Comment #12 from davek at gcc dot gnu dot org 2009-09-15 16:16 ---
(In reply to comment #11)
The bogus const info is added in at the end of this call chain, when
generating
the var die:
#0 0x004d0679 in add_const_value_attribute (die=0x7fcbd660, rtl=0x7fd20270)
at
--- Comment #13 from jakub at gcc dot gnu dot org 2009-09-15 16:42 ---
tls-local-exec for the VAR_DECL is not expected to me, I'd say it should be
TLS_MODEL_EMULATED for the !targetm.have_tls case. dwarf2out.c has no way
knowing the SYMBOL_REF needs special treatment, as when it is
--- Comment #14 from davek at gcc dot gnu dot org 2009-09-15 17:08 ---
Created an attachment (id=18586)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18586action=view)
reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41357
--- Comment #15 from davek at gcc dot gnu dot org 2009-09-15 17:16 ---
(In reply to comment #14)
Created an attachment (id=18586)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18586action=view) [edit]
reduced testcase
Ok, this is really interesting.
The generated debug
--- Comment #16 from jakub at gcc dot gnu dot org 2009-09-15 17:19 ---
Please read what I wrote.
vartrack uses cselib as a value numbering implementation, not for anything
else.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41357
--- Comment #17 from davek at gcc dot gnu dot org 2009-09-15 17:25 ---
(In reply to comment #16)
Please read what I wrote.
I did, but I'm a few steps behind, and haven't figured out whether to blame
encode_section_info() for being naive, or to look at where the SYM_REF gets
created
--- Comment #18 from davek at gcc dot gnu dot org 2009-09-15 17:36 ---
Created an attachment (id=18587)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18587action=view)
patch based on jakub's suggestion
this fixes the testcase, so I may as well take it for a full bootstrap cycle.
--- Comment #19 from hjl dot tools at gmail dot com 2009-09-15 17:41
---
Index: varasm.c
===
--- varasm.c(revision 151703)
+++ varasm.c(working copy)
@@ -6420,6 +6420,8 @@ default_encode_section_info (tree decl,
--- Comment #20 from jakub at gcc dot gnu dot org 2009-09-15 17:45 ---
See PR41353 for possible explanation. The last patch isn't complete there,
I'll post a fixed one once I do some further .debug_info analysis. Anyway,
that has nothing to do with this PR, a SYMBOL_REF for a tls
--- Comment #22 from davek at gcc dot gnu dot org 2009-09-15 17:57 ---
Created an attachment (id=18588)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18588action=view)
slightly reworked patch
slightly reworked per hj's suggestion
--
davek at gcc dot gnu dot org changed:
--- Comment #21 from davek at gcc dot gnu dot org 2009-09-15 17:51 ---
(In reply to comment #19)
Index: varasm.c
===
--- varasm.c(revision 151703)
+++ varasm.c(working copy)
@@ -6420,6 +6420,8 @@
24 matches
Mail list logo
