http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
m...@gcc.gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Known to work|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #51 from mrs at gcc dot gnu.org 2013-02-11
23:30:18 UTC ---
Author: mrs
Date: Mon Feb 11 23:30:10 2013
New Revision: 195960
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195960
Log:
/libgcc
2013-02-11 Iain Sandoe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #50 from Jack Howarth 2013-02-11
17:54:44 UTC ---
(In reply to comment #47)
> Created attachment 29396 [details]
> revised patch to revert r184293 while fixing PR55693
>
> Bootstrap regtesting underway on ppc darwin9, x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #49 from Jack Howarth 2013-02-08
18:17:50 UTC ---
The patch in comment 47 produces no regressions in gcc for...
make -k check RUNTESTFLAGS="tm.exp --target_board=unix'{-m32,-m64}'"
and none in libitm for...
make -k check
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #48 from Jack Howarth 2013-02-08
14:40:20 UTC ---
(In reply to comment #47)
> Created attachment 29396 [details]
> revised patch to revert r184293 while fixing PR55693
>
> Bootstrap regtesting underway on ppc darwin9, x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #47 from Jack Howarth 2013-02-08
14:39:11 UTC ---
Created attachment 29396
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29396
revised patch to revert r184293 while fixing PR55693
Bootstrap regtesting underway on ppc d
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #46 from Patrick Marlier
2013-02-08 11:46:33 UTC ---
Jack,
I am sorry to be picky but are dummy functions still required in
libgcc/config/darwin-crt-tm.c?
I haven't access to a machine with
__ENVIRONMENT_MAC_OS_X_VERSION_MI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #45 from Dominique d'Humieres
2013-02-07 21:59:38 UTC ---
> ... Bootstrap regression
> tested for tm.exp and libitm subdirectory on x86_64-apple-darwin10 with Xcode
> 4.2 and x86_64-apple-darwin12 with Xcode 4.6. Can someone te
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #44 from Jack Howarth 2013-02-07
19:33:24 UTC ---
Created attachment 29389
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29389
revised patch to fix darwin10 under Xcode 4.2
The attached patch removes the " && !defined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
m...@gcc.gnu.org changed:
What|Removed |Added
CC||mrs at gcc dot gnu.org
--- C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #42 from Jack Howarth 2013-01-25
13:23:12 UTC ---
Full regression testing on x86_64-apple-darwin12 of proposed patch to supply
dummy functions as a static archive shows no regressions in any tm tests...
http://gcc.gnu.org/ml/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #41 from Jack Howarth 2013-01-24
15:23:54 UTC ---
Iain,
I believe the current behavior of dyld in darwin10/11/12 is clearly
described in...
http://developer.apple.com/library/mac/#releasenotes/DeveloperTools/RN-dyld/_ind
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #40 from Jack Howarth 2013-01-24
14:54:34 UTC ---
(In reply to comment #39)
My understanding from Nick's comments was that the ld64/dyld behavior is
now as follows. For performance reasons, weak coalescing is only done if
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #39 from Iain Sandoe 2013-01-24 11:34:20
UTC ---
(In reply to comment #38)
> Tested proposed patch from Comment 37 on x86_64-apple-darwin11 and
> x86_64-apple-darwin12 with Xcode 4.5.2 on both systems. No regressions are
> fou
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #38 from Jack Howarth 2013-01-24
05:54:24 UTC ---
Tested proposed patch from Comment 37 on x86_64-apple-darwin11 and
x86_64-apple-darwin12 with Xcode 4.5.2 on both systems. No regressions are
found with either
make -k ch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #37 from Iain Sandoe 2013-01-23 22:16:10
UTC ---
Created attachment 29262
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29262
test, supply the dummy functions from a static archive.
in the current code, the following
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #36 from Jack Howarth 2013-01-23
21:27:41 UTC ---
The darwin linker developers comments on the testcase I uploaded were...
The term "weak" is way overloaded. The original bug was about "weak
definitions" which
is how C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #35 from Jack Howarth 2013-01-23
21:13:16 UTC ---
What's up with the comment
/* Provide dummy functions to satisfy linkage for versions of the Darwin
tool-chain that that can't handle undefined weak refs at the link s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #34 from Iain Sandoe 2013-01-23 20:35:47
UTC ---
(In reply to comment #24)
> However, in this case, the references *are* present on the link line (lstdc++)
> but also a duplicate in crttme.o
> since -lstdc++ is on the li
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #33 from Iain Sandoe 2013-01-23 20:14:26
UTC ---
(In reply to comment #32)
> (In reply to comment #31)
>
> > solution on darwin is to mark the duplicate symbols in crttme.o as weak.
>
> seems reasonable - can you try that?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #32 from Iain Sandoe 2013-01-23 19:59:40
UTC ---
(In reply to comment #31)
> solution on darwin is to mark the duplicate symbols in crttme.o as weak.
seems reasonable - can you try that?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #31 from Jack Howarth 2013-01-23
19:41:52 UTC ---
I believe the attached testcase, weak_symbol.tar.bz2, demonstrates that the
solution on darwin is to mark the duplicate symbols in crttme.o as weak.
Consider the following test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #30 from Jack Howarth 2013-01-23
19:32:22 UTC ---
Created attachment 29256
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29256
test case demonstrating need for weak symbols in crttme.o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #29 from Dominique d'Humieres
2013-01-23 18:30:37 UTC ---
(In reply to comment #27)
> > FWIW, I reproduced the problem on Darwin10 (x86_64-apple-darwin10.8.0).
> > Mac OS X 10.6.8.
>
> What Xcode do you have installed? Is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #28 from Jack Howarth 2013-01-23
17:32:34 UTC ---
Iain,
The ELF style weak ref issue appears to be red herring. I find that both
darwin10 with Xcode 4.2 (whose build of libitm has a config.h with
HAVE_ELF_STYLE_WEAKREF und
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #27 from Jack Howarth 2013-01-23
16:48:19 UTC ---
(In reply to comment #25)
> FWIW, I reproduced the problem on Darwin10 (x86_64-apple-darwin10.8.0).
> Mac OS X 10.6.8.
What Xcode do you have installed? Is it 3.2.6 or one
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #26 from Jack Howarth 2013-01-23
16:44:51 UTC ---
Iain,
The initial comments from the darwin linker developer were...
That test case is dying because a.out contains its own copy of
__cxa_allocate_exception which just re
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #25 from Aldy Hernandez 2013-01-23
14:11:53 UTC ---
> looks like (yet another) permutation of what works/doesn't with "ELF-style
> weak
> linking" I don't have darwin11 or 12 (yet) - but should do soon.
>
FWIW, I reproduced
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #24 from Iain Sandoe 2013-01-23 13:33:15
UTC ---
(In reply to comment #23)
> (In reply to comment #21)
> > ... I don't have darwin11 or 12 (yet) - but should do soon.
>
> The test also fails on darwin10 unless the patch in c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #23 from Dominique d'Humieres
2013-01-23 09:56:13 UTC ---
(In reply to comment #21)
> ... I don't have darwin11 or 12 (yet) - but should do soon.
The test also fails on darwin10 unless the patch in comment #7 is applied.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #21 from Iain Sandoe 2013-01-23 08:44:45
UTC ---
(In reply to comment #20)
> crttme.o comes from libgcc/config/darwin-crt-tm.c, which has:
>
> /* Provide dummy functions to satisfy linkage for versions of the Darwin
>to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
Aldy Hernandez changed:
What|Removed |Added
CC||patrick.marlier at gmail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #19 from Jack Howarth 2013-01-23
04:01:17 UTC ---
(In reply to comment #12)
> BTW, the reason this works when forcing the instrumented path as Torvald
> suggested (comment #7) is because when f1() is instrumented, the call to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #18 from Jack Howarth 2013-01-19
17:11:23 UTC ---
Opened radar://13048248 in case these failing test cases represent an unwinder
bug on darwin.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #17 from Jack Howarth 2013-01-18
22:15:37 UTC ---
A walk from f1 in the statically linked a.C testcase looks like...
(gdb) b f1
Breakpoint 1 at 0x11764: file a.C, line 2.
(gdb) disp/i $pc
(gdb) r
Starting program: /Use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #16 from Jack Howarth 2013-01-18
22:02:08 UTC ---
If I compile the failing test case from comment 10 with...
% g++-fsf-4.8 -static-libgcc -fgnu-tm a.C
% otool -L ./a.out
./a.out:
/usr/lib/libSystem.B.dylib (compatibilit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
Aldy Hernandez changed:
What|Removed |Added
AssignedTo|aldyh at gcc dot gnu.org|unassigned at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #14 from Aldy Hernandez 2013-01-18
17:14:56 UTC ---
> You can use DYLD_PRINT_BINDINGS to find out which __cxa_allocate_exception
> call
> is being used, it'll also give you the addresses so you can make sure that the
> right o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
Eric Christopher changed:
What|Removed |Added
CC||echristo at gmail dot com
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #12 from Aldy Hernandez 2013-01-17
18:43:45 UTC ---
BTW, the reason this works when forcing the instrumented path as Torvald
suggested (comment #7) is because when f1() is instrumented, the call to
__cxa_allocate_exception is a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
Aldy Hernandez changed:
What|Removed |Added
CC||echristo at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #9 from Richard Henderson 2013-01-15
19:13:44 UTC ---
Unfortunately, the gdb trace in #c1 isn't enough to see what's
actually failing.
What *ought* to be happening is that the uninstrumented code path runs,
f1 makes two call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #8 from Jack Howarth 2013-01-12
03:24:55 UTC ---
(In reply to comment #7)
> The gdb trace looks alright to me. My guess is that this is a bug in the
> uninstrumented code path, not in libitm.
>
> Could you try again after a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
torvald at gcc dot gnu.org changed:
What|Removed |Added
CC||torvald at gcc dot gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
47 matches
Mail list logo
