https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906
--- Comment #59 from GCC Commits ---
The releases/gcc-11 branch has been updated by Iain D Sandoe
:
https://gcc.gnu.org/g:17212f5912d8f57b3757633444ae64c9831aa8f7
commit r11-11356-g17212f5912d8f57b3757633444ae64c9831aa8f7
Author: Iain Sandoe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906
--- Comment #58 from GCC Commits ---
The releases/gcc-12 branch has been updated by Iain D Sandoe
:
https://gcc.gnu.org/g:ab4ff3e9fe881ef85a8156f2be528872c6a2fdfc
commit r12-10336-gab4ff3e9fe881ef85a8156f2be528872c6a2fdfc
Author: Iain Sandoe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906
--- Comment #57 from CVS Commits ---
The master branch has been updated by Iain D Sandoe :
https://gcc.gnu.org/g:a044c9d25972b22c6b4c8ec27f2de5fd622573cc
commit r13-4482-ga044c9d25972b22c6b4c8ec27f2de5fd622573cc
Author: Iain Sandoe
Date:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906
--- Comment #54 from Jonathan Wakely redi at gcc dot gnu.org 2012-02-07
09:19:35 UTC ---
Author: redi
Date: Tue Feb 7 09:19:27 2012
New Revision: 183955
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183955
Log:
libgcc/
PR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906
--- Comment #55 from Jonathan Wakely redi at gcc dot gnu.org 2012-02-07
09:21:13 UTC ---
this should be fixed now - I won't close it until someone can verify it on
darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906
Jack Howarth howarth at nitro dot med.uc.edu changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906
--- Comment #53 from Jonathan Wakely redi at gcc dot gnu.org 2012-02-04
13:38:57 UTC ---
I did think about fixincludes, but that would undef
PTHREAD_RECURSIVE_MUTEX_INITIALIZER for everyone, whereas we only really need
to undef the gthr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906
--- Comment #39 from Iain Sandoe iains at gcc dot gnu.org 2012-02-03 08:22:56
UTC ---
(In reply to comment #37)
(In reply to comment #36)
You would probably have to use Availability.h and something like...
This is not required, (and likely
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906
--- Comment #40 from Jonathan Wakely redi at gcc dot gnu.org 2012-02-03
08:46:20 UTC ---
Created attachment 26558
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26558
disable __GTHREAD_RECURSIVE_MUTEX_INIT for Lion
Thanks, Iain.
I'm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906
--- Comment #41 from Iain Sandoe iains at gcc dot gnu.org 2012-02-03 09:04:02
UTC ---
(In reply to comment #40)
Created attachment 26558 [details]
disable __GTHREAD_RECURSIVE_MUTEX_INIT for Lion
Thanks, Iain.
I'm thinking of something
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906
--- Comment #42 from Jonathan Wakely redi at gcc dot gnu.org 2012-02-03
09:18:36 UTC ---
That header isn't even installed, let alone included, on other targets
Jack, if you test it please change == to = in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906
--- Comment #43 from Jack Howarth howarth at nitro dot med.uc.edu 2012-02-03
17:00:49 UTC ---
(In reply to comment #42)
That header isn't even installed, let alone included, on other targets
Jack, if you test it please change == to = in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906
--- Comment #44 from Iain Sandoe iains at gcc dot gnu.org 2012-02-03 17:14:43
UTC ---
if you are saying that:
code targeted at 10.6 produced on 10.7 (using the correct 10.6 SDK) doesn't run
properly on 10.7
- no surprise - that's just exposing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906
--- Comment #45 from Jonathan Wakely redi at gcc dot gnu.org 2012-02-03
17:16:38 UTC ---
Then I think we have to disable __GTHREAD_RECURSIVE_MUTEX_INIT unconditionally
on darwin.
If the bug is later fixed in (say) 10.8 then we could use the init
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906
--- Comment #46 from Iain Sandoe iains at gcc dot gnu.org 2012-02-03 17:27:30
UTC ---
(In reply to comment #45)
Then I think we have to disable __GTHREAD_RECURSIVE_MUTEX_INIT unconditionally
on darwin.
I hope not.
putting
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906
--- Comment #47 from Jack Howarth howarth at nitro dot med.uc.edu 2012-02-03
17:37:54 UTC ---
(In reply to comment #46)
(In reply to comment #45)
Then I think we have to disable __GTHREAD_RECURSIVE_MUTEX_INIT
unconditionally
on darwin.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906
--- Comment #48 from Jack Howarth howarth at nitro dot med.uc.edu 2012-02-03
17:45:21 UTC ---
(In reply to comment #46)
Actually, using -mmacosx-version-min=10.6
--sysroot=/Developer/SDKs/MacOSX10.6.sdk doesn't work as you end up with the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906
--- Comment #49 from Jonathan Wakely redi at gcc dot gnu.org 2012-02-03
17:50:07 UTC ---
(In reply to comment #46)
(In reply to comment #45)
Then I think we have to disable __GTHREAD_RECURSIVE_MUTEX_INIT
unconditionally
on darwin.
I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906
--- Comment #50 from Jonathan Wakely redi at gcc dot gnu.org 2012-02-03
17:52:39 UTC ---
(In reply to comment #48)
(In reply to comment #46)
Actually, using -mmacosx-version-min=10.6
--sysroot=/Developer/SDKs/MacOSX10.6.sdk doesn't work as
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906
--- Comment #51 from Iain Sandoe iains at gcc dot gnu.org 2012-02-03 17:56:29
UTC ---
(In reply to comment #49)
(In reply to comment #46)
(In reply to comment #45)
Then I think we have to disable __GTHREAD_RECURSIVE_MUTEX_INIT
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906
--- Comment #52 from Mike Stump mikestump at comcast dot net 2012-02-03
20:44:16 UTC ---
OK. I'd missed that - in which case no objection to the unconditional disable
from me.
We can even fixincludes it away! I'm fine with #undef or some
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906
--- Comment #36 from Jonathan Wakely redi at gcc dot gnu.org 2012-02-03
01:45:48 UTC ---
is there a Mac OS X version macro that libstdc++ can check to workaround the
bug, or should we just assume it will be fixed and users will have a working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906
--- Comment #37 from Jack Howarth howarth at nitro dot med.uc.edu 2012-02-03
02:14:52 UTC ---
(In reply to comment #36)
is there a Mac OS X version macro that libstdc++ can check to workaround the
bug, or should we just assume it will be fixed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906
--- Comment #38 from Jack Howarth howarth at nitro dot med.uc.edu 2012-02-03
02:39:01 UTC ---
(In reply to comment #37)
Actually that above approach won't work because the pthread.h header on
darwin11 always sources...
#if
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906
--- Comment #31 from Jonathan Wakely redi at gcc dot gnu.org 2012-01-31
11:23:55 UTC ---
(In reply to comment #30)
it outputs 22
and it returns 0 with _XOPEN_SOURCE defined?
which appears to be...
The pthread_mutex_lock() and
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906
--- Comment #32 from Jack Howarth howarth at nitro dot med.uc.edu 2012-01-31
14:56:36 UTC ---
(In reply to comment #31)
FYI, the example code for pthread_mutex_trylock at...
http://ptgmedia.pearsoncmg.com/images/0201633922/sourcecode/trylock.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906
--- Comment #33 from Jonathan Wakely redi at gcc dot gnu.org 2012-01-31
15:27:47 UTC ---
Unsurprising. That code only statically-allocates a mutex, doesn't use C++
non-static data member initializers and doesn't use a recursive mutex (from the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906
Greg Parker gparker at apple dot com changed:
What|Removed |Added
CC||gparker at apple
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906
--- Comment #22 from Jack Howarth howarth at nitro dot med.uc.edu 2012-01-30
14:42:48 UTC ---
(In reply to comment #21)
That gdb session in comment 18 makes no sense, owns_lock can't call trylock.
Your sources don't match your lib.
I thought
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906
--- Comment #23 from Jack Howarth howarth at nitro dot med.uc.edu 2012-01-30
18:04:44 UTC ---
The 30_threads/recursive_mutex/try_lock/1.cc execution test on darwin11 built
with gcc trunk against Xcode 4.2.1 shows...
(gdb) break main
Breakpoint
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906
--- Comment #24 from Jonathan Wakely redi at gcc dot gnu.org 2012-01-31
00:01:41 UTC ---
That debug session still doesn't make much sense, are you debugging an
optimised executable? I don't need a more detailed trace, just one that
actually
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906
--- Comment #25 from Jack Howarth howarth at nitro dot med.uc.edu 2012-01-31
01:03:33 UTC ---
(In reply to comment #24)
Here is a trace for
libstdc++-v3/testsuite/30_threads/recursive_mutex/try_lock/1.cc compiled at
-O0 with...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906
--- Comment #26 from Jack Howarth howarth at nitro dot med.uc.edu 2012-01-31
01:05:15 UTC ---
Created attachment 26525
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26525
preprocessed source from FSF gcc 4.7 for pthread test code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906
--- Comment #27 from Jack Howarth howarth at nitro dot med.uc.edu 2012-01-31
01:07:40 UTC ---
(In reply to comment #24)
I've attached the preprocessed source from FSF gcc 4.7 on darwin11 for your
proposed pthread test program, as pthread_test.i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906
--- Comment #28 from Jonathan Wakely redi at gcc dot gnu.org 2012-01-31
01:15:00 UTC ---
You need to use g++ (not gcc) to compile C++ code, and you need to use
-std=c++0x to compile C++11 code. GCC 4.2 doesn't support -std=c++0x so
there's no
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906
--- Comment #29 from Jonathan Wakely redi at gcc dot gnu.org 2012-01-31
01:18:37 UTC ---
It might be easier if I to get access to a darwin system, which I should have
in a few days so I can test it myself.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906
--- Comment #30 from Jack Howarth howarth at nitro dot med.uc.edu 2012-01-31
02:25:31 UTC ---
(In reply to comment #29)
It might be easier if I to get access to a darwin system, which I should have
in a few days so I can test it myself.
Okay,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906
--- Comment #18 from Jack Howarth howarth at nitro dot med.uc.edu 2012-01-29
15:30:12 UTC ---
Here is a single stepping through 30_threads/try_lock/3.cc at -m64...
(gdb) break main
Breakpoint 1 at 0x10cd0: file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906
--- Comment #19 from Iain Sandoe iains at gcc dot gnu.org 2012-01-29 15:37:45
UTC ---
could you also let me know what the value of
HAVE_AS_TLS
is in gcc/auto-host.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906
--- Comment #20 from Jack Howarth howarth at nitro dot med.uc.edu 2012-01-29
15:54:59 UTC ---
(In reply to comment #19)
could you also let me know what the value of
HAVE_AS_TLS
is in gcc/auto-host.h
Both the darwin10 build (without this
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906
--- Comment #21 from Jonathan Wakely redi at gcc dot gnu.org 2012-01-29
22:36:34 UTC ---
That gdb session in comment 18 makes no sense, owns_lock can't call trylock.
Your sources don't match your lib.
I thought this was a problem with WARNING:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906
--- Comment #9 from Jack Howarth howarth at nitro dot med.uc.edu 2012-01-28
16:47:49 UTC ---
Created attachment 26490
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26490
preprocessed source for
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906
--- Comment #10 from Jack Howarth howarth at nitro dot med.uc.edu 2012-01-28
16:48:37 UTC ---
Created attachment 26491
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26491
preprocessed source for
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906
--- Comment #11 from Jack Howarth howarth at nitro dot med.uc.edu 2012-01-28
16:49:14 UTC ---
Created attachment 26492
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26492
diff of preprocessed source for
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906
--- Comment #12 from Jack Howarth howarth at nitro dot med.uc.edu 2012-01-28
16:52:24 UTC ---
The contents of 3.ii.diff seems to suggest that the problem is the fact that
Lion always defines _GTHREAD_RECURSIVE_MUTEX_INIT and this support is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906
--- Comment #13 from Jonathan Wakely redi at gcc dot gnu.org 2012-01-28
19:16:37 UTC ---
(In reply to comment #12)
The contents of 3.ii.diff seems to suggest that the problem is the fact that
Lion always defines _GTHREAD_RECURSIVE_MUTEX_INIT
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906
--- Comment #14 from Jack Howarth howarth at nitro dot med.uc.edu 2012-01-28
22:14:36 UTC ---
(In reply to comment #13)
I'm not having much luck getting the test case to compile on darwin11. If I
use...
#include pthread.h
struct mutex {
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906
--- Comment #15 from Jack Howarth howarth at nitro dot med.uc.edu 2012-01-28
23:14:09 UTC ---
Note that all three failing test cases on Lion pass if I append -D_XOPEN_SOURCE
to the compilation flags for those tests.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906
--- Comment #16 from Jonathan Wakely redi at gcc dot gnu.org 2012-01-29
00:42:38 UTC ---
(In reply to comment #14)
I'm not having much luck getting the test case to compile on darwin11.
Did you use -std=c++0x? (or -std=c++11)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906
--- Comment #17 from Jonathan Wakely redi at gcc dot gnu.org 2012-01-29
00:47:05 UTC ---
also, stack trace please. it's not easy to debug problems on systems I don't
have access to when I have to guess what the program does.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906
--- Comment #8 from Jack Howarth howarth at nitro dot med.uc.edu 2012-01-27
17:36:08 UTC ---
Opened as radr://10765474, darwin11 linker bug exposed by new libstdc++ thread
tests although it appears to be more complex than a simple linker bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906
--- Comment #7 from Jack Howarth howarth at nitro dot med.uc.edu 2012-01-21
22:11:12 UTC ---
This issue is starting to look like a darwin11-specific linker bug. If I build
the 30_threads/recursive_mutex/try_lock/1.cc test case under Xcode 4.2 on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906
--- Comment #6 from Jack Howarth howarth at nitro dot med.uc.edu 2012-01-20
14:35:52 UTC ---
(In reply to comment #4)
On x86_64-darwin10 (Xcode 3.2.6) r183290 is OK.
On powerpc-apple-darwin9 (Xcode 3.1.4) 183218 is OK.
This issue doesn't occur
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2012-01-19
19:58:04 UTC ---
have they been failing since I enabled them by fixing PR 50196 ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906
--- Comment #2 from Iain Sandoe iains at gcc dot gnu.org 2012-01-19 20:16:10
UTC ---
not failing on
*-darwin9 @r183184/r183270 (ppc/i686)
[deallocate_global_thread errors remain present there, and not due to emutls
issues]
checking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906
--- Comment #3 from Jack Howarth howarth at nitro dot med.uc.edu 2012-01-19
20:20:26 UTC ---
(In reply to comment #1)
have they been failing since I enabled them by fixing PR 50196 ?
I haven't done a complete regression hunt yet but the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906
--- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-01-19
20:27:50 UTC ---
On x86_64-darwin10 (Xcode 3.2.6) r183290 is OK.
On powerpc-apple-darwin9 (Xcode 3.1.4) 183218 is OK.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906
--- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2012-01-19
20:50:18 UTC ---
(In reply to comment #3)
but r180136 (prior to the PR 50196 fix commit) doesn't show these (or any)
failures in libstdc++.
It's unsurprising that the tests
59 matches
Mail list logo
