--- 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=18596&action=view)
YA respin
don't copy tls model into rtl flags for TLS_MODEL_EMULATED, only other values.
--
davek at gcc dot
--- 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 in
--- 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 th
--- 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=18595&action=view)
simplified fix
After discussion on the -patches list, it seemed sensible to try preserving the
precise value of
--- 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 @@ default_en
--- 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=18588&action=view)
slightly reworked patch
slightly reworked per hj's suggestion
--
davek at gcc dot gnu dot org changed:
--- 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 symbo
--- 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, rtx
--- 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=18587&action=view)
patch based on jakub's suggestion
this fixes the testcase, so I may as well take it for a full bootstrap cycle.
--- 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 #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 #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=18586&action=view) [edit]
> reduced testcase
>
Ok, this is really interesting.
The generated debu
--- 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=18586&action=view)
reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41357
--- 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 crea
--- 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 #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 0x004d2
--- 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_tl
--- 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 ex
--- 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 n
--- 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 #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:
<1>: Abbrev Number: 49 (DW_TAG_variable)
DW_AT_name
--- 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 #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.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=
--- 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
-B/gnu/gcc/ob
24 matches
Mail list logo
