--- Comment #22 from ktietz at gcc dot gnu dot org 2010-05-21 11:28 ---
Patch fron comment #14 applied to trunk.
Back-port won't be done as there is a risc of emutls-fallout (as Richard
mentioned in his approval).
Committed at revision 159658.
--
ktietz at gcc dot gnu dot org change
--- Comment #21 from dje at gcc dot gnu dot org 2010-05-20 17:52 ---
I tested the patch from comment #14 on top of the DECL_PRESERVE_P patch from PR
44132, which was necessary to get back to a sane level of C++ and libgomp
failures on AIX. The DECL_DLLIMPORT_P and DECL_ATTRIBUTES patch
--- Comment #20 from ktietz at gcc dot gnu dot org 2010-05-19 16:18 ---
(In reply to comment #19)
> What is the relationship between this bug and PR 44132? Richi and Honza seem
> to prefer the DECL_PRESERVE_P hack. We will see if Iain's lowering works. I
> don't think both the decl at
--- Comment #19 from dje at gcc dot gnu dot org 2010-05-19 15:40 ---
What is the relationship between this bug and PR 44132? Richi and Honza seem
to prefer the DECL_PRESERVE_P hack. We will see if Iain's lowering works. I
don't think both the decl attribute merging patch and DECL_PRES
--- Comment #18 from ktietz at gcc dot gnu dot org 2010-05-19 09:15 ---
Hi David,
Could you test the suggested patch for AIX? Richard told me that the patch is
sensible, but the attribute merging is something to be tested for AIX.
Thanks in advance,
Kai
--
ktietz at gcc dot gnu dot
--- Comment #17 from dannysmith at users dot sourceforge dot net
2010-05-18 22:43 ---
(In reply to comment #14)
> Index: gcc/gcc/varasm.c
> ===
> --- gcc.orig/gcc/varasm.c 2010-05-18 13:19:20.0 +0200
> +++ gcc
--- Comment #16 from dominiq at lps dot ens dot fr 2010-05-18 16:28 ---
You may be interested by pr 44132.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44139
--- Comment #15 from davek at gcc dot gnu dot org 2010-05-18 15:26 ---
(In reply to comment #14)
> Hi Dave,
>
> following patch solves the issue for me pretty well.
That looks good to me to, although doing it in the middle-end makes me worry
that some other target might /not/ be expect
--- Comment #14 from ktietz at gcc dot gnu dot org 2010-05-18 15:18 ---
Hi Dave,
following patch solves the issue for me pretty well.
ChangeLog
* varasm.c (emutls_decl): Clone attributes for new decl.
Index: gcc/gcc/varasm.c
=
--- Comment #13 from davek at gcc dot gnu dot org 2010-05-18 14:33 ---
(In reply to comment #12)
> TARGET_EMUTLS_VAR_INIT
Nah, scratch that, it's not really sensible.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44139
--- Comment #12 from davek at gcc dot gnu dot org 2010-05-18 14:29 ---
(In reply to comment #11)
> I have doubts about the approach in winnt.c, but well maybe I am wrong here. I
> investigated for this issue and see the real issue in declaration cloning in
> varasm.c's emutls_decl- func
--- Comment #11 from ktietz at gcc dot gnu dot org 2010-05-18 14:22 ---
(In reply to comment #10)
> Re-opening. It turns out that GCC fails to actually apply the dllexport
> attribute to TLS control vars. So solving the binutils problem allows
> auto-export of a TLS variable to work, b
--
davek at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |davek at gcc dot gnu dot org
|dot org
--- Comment #10 from davek at gcc dot gnu dot org 2010-05-17 18:25 ---
Re-opening. It turns out that GCC fails to actually apply the dllexport
attribute to TLS control vars. So solving the binutils problem allows
auto-export of a TLS variable to work, but as auto-export gets disabled i
--- Comment #9 from davek at gcc dot gnu dot org 2010-05-15 13:48 ---
FTR: Patch posted at http://sourceware.org/ml/binutils/2010-05/msg00171.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44139
--- Comment #8 from dougsemler at gmail dot com 2010-05-15 13:03 ---
Done
cf. http://sourceware.org/bugzilla/show_bug.cgi?id=11603
(note to self, pay more attention to specs and less attention to de facto
behavior of toolsets ;-))
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=441
--- Comment #7 from davek at gcc dot gnu dot org 2010-05-15 09:45 ---
So... I think now we just need to figure out how to tell LD that some export
directives contain dots because they're exporting a symbol containing a dot.
Actually, that's probably all we need to do: when we find an ex
--- Comment #6 from davek at gcc dot gnu dot org 2010-05-15 09:38 ---
Created an attachment (id=20668)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20668&action=view)
testcase: makefile
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44139
--- Comment #5 from davek at gcc dot gnu dot org 2010-05-15 09:38 ---
Created an attachment (id=20667)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20667&action=view)
testcase: dll header
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44139
--- Comment #4 from davek at gcc dot gnu dot org 2010-05-15 09:37 ---
Created an attachment (id=20666)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20666&action=view)
testcase: dll source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44139
--- Comment #3 from davek at gcc dot gnu dot org 2010-05-15 09:37 ---
Created an attachment (id=20665)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20665&action=view)
testcase: main executable source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44139
--- Comment #2 from davek at gcc dot gnu dot org 2010-05-15 09:34 ---
(In reply to comment #1)
> In other words, I don't think the runtime loader actually keys off the
> presence
> of a dot in the exported symbol, but where the EAT entry points to. If we can
> persuade ld that sometim
--- Comment #1 from davek at gcc dot gnu dot org 2010-05-15 09:06 ---
(In reply to comment #0)
> Windows targets that use emutls add a "." character as a separator from the
> _emutls_{t,v} and the true symbol name. However, exporting these symbol names
> from a DLL is problematic (i.e.
23 matches
Mail list logo
