--- Comment #28 from danglin at gcc dot gnu dot org 2006-10-10 22:26
---
Fixed.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #27 from bkoz at gcc dot gnu dot org 2006-10-10 10:14 ---
Subject: Bug 29118
Author: bkoz
Date: Tue Oct 10 10:14:13 2006
New Revision: 117600
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117600
Log:
2006-10-09 Benjamin Kosnik <[EMAIL PROTECTED]>
PR libst
--- Comment #26 from bkoz at gcc dot gnu dot org 2006-10-10 09:54 ---
Ok. I think I'll put this in.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29118
--- Comment #25 from dave at hiauly1 dot hia dot nrc dot ca 2006-10-09
16:27 ---
Subject: Re: [4.2 Regression] Timeouts in libstdc++, libjava and libgomp
testsuites
> Hey Dave. Thanks for your persistence on this one: I think it's paid off. I
> can
> see what you are talking about WR
--- Comment #24 from bkoz at gcc dot gnu dot org 2006-10-09 10:32 ---
Hey Dave. Thanks for your persistence on this one: I think it's paid off. I can
see what you are talking about WRT mutex initialization, and have high hopes
for the attached patch. If you can try it, and let me know t
--- Comment #23 from bkoz at gcc dot gnu dot org 2006-10-09 10:26 ---
Created an attachment (id=12399)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12399&action=view)
patch for mutex init
Can you try this? thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29118
--- Comment #22 from dave at hiauly1 dot hia dot nrc dot ca 2006-10-08
17:09 ---
Subject: Re: [4.2 Regression] Timeouts in libstdc++, libjava and libgomp
testsuites
> Couldn't the constructor for locale possibly run before the one
> for the locale_mutex?
The ordering issue is confirm
--- Comment #21 from dave at hiauly1 dot hia dot nrc dot ca 2006-10-07
20:11 ---
Subject: Re: [4.2 Regression] Timeouts in libstdc++, libjava and libgomp
testsuites
> I don't think this is an ordering problem... there are no complicated ordering
> issues in this code. Something to try
--- Comment #20 from dave at hiauly1 dot hia dot nrc dot ca 2006-10-07
20:02 ---
Subject: Re: [4.2 Regression] Timeouts in libstdc++, libjava and libgomp
testsuites
> It appears we hang at the "once_masterlock" line. We never get to
> the next line.
Oops, that should have read "_S_i
--- Comment #19 from dave at hiauly1 dot hia dot nrc dot ca 2006-10-07
19:51 ---
Subject: Re: [4.2 Regression] Timeouts in libstdc++, libjava and libgomp
testsuites
> > When you get to "break here" this is what your mutex should look like in
> > gdb:
>
> Well, we don't actually get
--- Comment #18 from dave at hiauly1 dot hia dot nrc dot ca 2006-10-07
18:56 ---
Subject: Re: [4.2 Regression] Timeouts in libstdc++, libjava and libgomp
testsuites
> --- Comment #16 from bkoz at gcc dot gnu dot org 2006-10-06 09:52 ---
> When you get to "break here" this is
--- Comment #17 from bkoz at gcc dot gnu dot org 2006-10-06 09:55 ---
I don't think this is an ordering problem... there are no complicated ordering
issues in this code. Something to try might be making test_mutex static, and
not in an anonymous namespace.
I'm not quite sure why hppa i
--- Comment #16 from bkoz at gcc dot gnu dot org 2006-10-06 09:52 ---
When you get to "break here" this is what your mutex should look like in gdb:
Breakpoint 2, add () at lock_test.cc:14
(gdb) p test_mutex
$4 = {_M_mutex = {__data = {__lock = 1, __count = 0, __owner = 14845,
__k
--- Comment #15 from bkoz at gcc dot gnu dot org 2006-10-06 09:48 ---
// try this simpler code.
#include
#include
namespace
{
__gnu_cxx::__mutex test_mutex;
unsigned int i;
} // anonymous namespace
void* add(void*)
{
__gnu_cxx::__scoped_lock sentry(test_mutex);
{
++i; //
--- Comment #14 from dave at hiauly1 dot hia dot nrc dot ca 2006-09-23
21:33 ---
Subject: Re: [4.2 Regression] Timeouts in libstdc++, libjava and libgomp
testsuites
> Breakpoint 1, 0x40b4c6bc in *__GI___pthread_mutex_lock (mutex=0x41c6)
(gdb) p locale_mutex
$2 = {_M_mutex = {__m_
--- Comment #13 from dave at hiauly1 dot hia dot nrc dot ca 2006-09-23
20:18 ---
Subject: Re: [4.2 Regression] Timeouts in libstdc++, libjava and libgomp
testsuites
> Of these, 19_diagnostics/23591_thread-1.c is probably the easiest to debug.
We seem to have an uninitialized mutex:
--- Comment #12 from dave at hiauly1 dot hia dot nrc dot ca 2006-09-23
19:25 ---
Subject: Re: [4.2 Regression] Timeouts in libstdc++, libjava and libgomp
testsuites
> One thing you could try, to confirm that this is what's up, is to replace the
> hppa atomics config with the generic p
--- Comment #11 from dave at hiauly1 dot hia dot nrc dot ca 2006-09-23
18:03 ---
Subject: Re: [4.2 Regression] Timeouts in libstdc++, libjava and libgomp
testsuites
> > Does hpux use the hppa atomics config, or the generic layer? If it uses the
> > hppa atomics config, why isn't this
--- Comment #10 from dave at hiauly1 dot hia dot nrc dot ca 2006-09-22
14:49 ---
Subject: Re: [4.2 Regression] Timeouts in libstdc++, libjava and libgomp
testsuites
> Does hpux use the hppa atomics config, or the generic layer? If it uses the
> hppa atomics config, why isn't this a pr
--- Comment #9 from bkoz at gcc dot gnu dot org 2006-09-21 20:26 ---
Also:
Does hpux use the hppa atomics config, or the generic layer? If it uses the
hppa atomics config, why isn't this a problem on hpux?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29118
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bkoz at gcc dot gnu dot org
|dot org
--- Comment #8 from bkoz at gcc dot gnu dot org 2006-09-21 20:24 ---
> I applied r116954 to 116942.
Well, then it's still my patch or patches then. Sorry.
> It's still using linuxthreads. Also because of the limitations
> of the ldcw semaphore instruction in PA 1.1, the atomic lock
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29118
--- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2006-09-20
23:33 ---
Subject: Re: [4.2 Regression] Timeouts in libstdc++, libjava and libgomp
testsuites
> Huh. Dave, is revision 116942M the same as revision 116942?
I applied r116954 to 116942.
> Of these, 19_diagnostics/
--- Comment #6 from bkoz at gcc dot gnu dot org 2006-09-20 15:18 ---
Huh. Dave, is revision 116942M the same as revision 116942?
Of these, 19_diagnostics/23591_thread-1.c is probably the easiest to debug.
Since this is the linux target, and not the hpux target, the code paths for the
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-09-20 04:40 ---
http://gcc.gnu.org/viewcvs?view=rev&revision=116942
This is why I mentioned some of the libstdc++ changes should not be going in.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
26 matches
Mail list logo
