--- Comment #3 from davek at gcc dot gnu dot org 2010-05-02 23:56 ---
Applied to trunk at r.158983.
--
davek at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from davek at gcc dot gnu dot org 2010-05-03 00:18 ---
Ow. Still present on mainline. This really needs a C++ F/E expert to look at
it.
--
davek at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from davek at gcc dot gnu dot org 2010-05-06 16:06 ---
Subject: Bug 43888
Author: davek
Date: Thu May 6 16:06:18 2010
New Revision: 159111
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159111
Log:
PR target/43888
* config/i386
--- Comment #15 from davek at gcc dot gnu dot org 2010-05-06 16:21 ---
Subject: Bug 42811
Author: davek
Date: Thu May 6 16:20:53 2010
New Revision: 159115
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159115
Log:
PR target/42811
* tests/staticrootstes
--- Comment #17 from davek at gcc dot gnu dot org 2010-05-09 21:00 ---
Thank you!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10676
--- Comment #17 from davek at gcc dot gnu dot org 2010-05-10 20:54 ---
(In reply to comment #16)
> On alphaev68-pc-linux-gnu, I'm getting:
> FAIL: leaktest
> 1 of 4 tests failed
> Is this failure something to worry about?
The honest answer is: I can't tell you.
--- Comment #19 from davek at gcc dot gnu dot org 2010-05-12 16:48 ---
(In reply to comment #18)
> FYI, the same failure happens on x86_64-pc-linux-gnu, but is silent for some
> reason:
> Leaked composite object at 0x2b5d6f749ef0
> (../../../gcc-svn/trunk/boehm-gc/tests/le
--- Comment #23 from davek at gcc dot gnu dot org 2010-05-12 22:20 ---
(In reply to comment #22)
> Hm, I'm not able to run thread_test.c and thread_leak_test.c tests using "make
> -k check", so otherwise deadly trivial patch can't be fully tested.
>
Well I
--- 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
--- 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
>
--- 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 #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 #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 #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 #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
--- 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 #2 from davek at gcc dot gnu dot org 2010-05-17 17:02 ---
Yes, it certainly does, in fact it omits to compile any definition for 'foo'
whatsoever!
But isn't this the expected behaviour of using '-fwhole-program' on something
that is not the whole
--- 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
--
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 #3 from davek at gcc dot gnu dot org 2010-05-17 18:28 ---
Consensus seems to be that this is indeed "how it's meant to work", but that
figuring out which are the externally visible functions and marking them
automatically would be a nice enhancement that
--- 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'
--- 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 #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
y: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: davek at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44321
--- Comment #1 from davek at gcc dot gnu dot org 2010-05-29 11:33 ---
Created an attachment (id=20771)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20771&action=view)
testcase as per initial comment.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44321
--- Comment #50 from davek at gcc dot gnu dot org 2010-06-14 10:38 ---
Subject: Bug 42776
Author: davek
Date: Mon Jun 14 10:38:18 2010
New Revision: 160722
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160722
Log:
ChangeLog:
Backport from mainline:
2010-04-27 D
--- Comment #5 from davek at gcc dot gnu dot org 2010-07-09 00:21 ---
Subject: Bug 43888
Author: davek
Date: Fri Jul 9 00:20:58 2010
New Revision: 161982
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161982
Log:
2010-07-09 Dave Korn
Backport from
--- Comment #6 from davek at gcc dot gnu dot org 2010-07-11 12:56 ---
(In reply to comment #5)
> Program received signal SIGSEGV, Segmentation fault.
> 0x006f25bd in lvalue_p_1 (ref=0x70c4fb98) at
> ../../gcc-4.x/gcc/cp/tree.c:71
> 71if (TREE_CODE (TR
--- Comment #11 from davek at gcc dot gnu dot org 2010-07-12 00:14 ---
(In reply to comment #10)
> (In reply to comment #2)
> > I can't reproduce it with r161865. (on x86_64-linux with -m32)
> >
>
> please confirm that this error introduces from -O
301 - 329 of 329 matches
Mail list logo
