[Bug libstdc++/29118] New: Timeouts in libstdc++, libjava and libgomp testsuites

[Bug libstdc++/29118] New: Timeouts in libstdc++, libjava and libgomp testsuites

[danglin at gcc dot gnu dot org]

=== libstdc++ tests ===


Running target unix
WARNING: program timed out.
FAIL: 19_diagnostics/23591_thread-1.c execution test
...
WARNING: program timed out.
FAIL: ext/mt_allocator/22309_thread.cc execution test
WARNING: program timed out.
FAIL: thread/18185.cc execution test
WARNING: program timed out.
FAIL: thread/pthread1.cc execution test
WARNING: program timed out.
FAIL: thread/pthread2.cc execution test
WARNING: program timed out.
FAIL: thread/pthread3.cc execution test
WARNING: program timed out.
FAIL: thread/pthread4.cc execution test
WARNING: program timed out.
FAIL: thread/pthread5.cc execution test
WARNING: program timed out.
FAIL: thread/pthread6.cc execution test
WARNING: program timed out.
FAIL: thread/pthread7-rope.cc execution test
WARNING: program timed out.
FAIL: tr1/2_general_utilities/memory/shared_ptr/thread/default_weaktoshared.cc
execution test
WARNING: program timed out.
FAIL: tr1/2_general_utilities/memory/shared_ptr/thread/mutex_weaktoshared.cc
execution test

                === libjava tests ===


Running target unix
WARNING: program timed out.
FAIL: cxxtest run

                === libgomp tests ===


Running target unix
WARNING: program timed out.
FAIL: libgomp.c++/ctor-1.C  -O0  execution test
WARNING: program timed out.
FAIL: libgomp.c++/ctor-1.C  -O1  execution test
WARNING: program timed out.
FAIL: libgomp.c++/ctor-1.C  -O2  execution test
WARNING: program timed out.
FAIL: libgomp.c++/ctor-1.C  -O3 -fomit-frame-pointer  execution test
WARNING: program timed out.
FAIL: libgomp.c++/ctor-1.C  -O3 -fomit-frame-pointer -funroll-loops  execution
test
WARNING: program timed out.
FAIL: libgomp.c++/ctor-1.C  -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions  execution test
WARNING: program timed out.
FAIL: libgomp.c++/ctor-1.C  -O3 -g  execution test
WARNING: program timed out.
FAIL: libgomp.c++/ctor-1.C  -Os  execution test
WARNING: program timed out.
FAIL: libgomp.c++/ctor-2.C  -O0  execution test
WARNING: program timed out.
FAIL: libgomp.c++/ctor-2.C  -O1  execution test
WARNING: program timed out.
FAIL: libgomp.c++/ctor-2.C  -O2  execution test
WARNING: program timed out.
FAIL: libgomp.c++/ctor-2.C  -O3 -fomit-frame-pointer  execution test
WARNING: program timed out.
FAIL: libgomp.c++/ctor-2.C  -O3 -fomit-frame-pointer -funroll-loops  execution
test
WARNING: program timed out.
FAIL: libgomp.c++/ctor-2.C  -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions  execution test
WARNING: program timed out.
FAIL: libgomp.c++/ctor-2.C  -O3 -g  execution test
WARNING: program timed out.
FAIL: libgomp.c++/ctor-2.C  -Os  execution test
WARNING: program timed out.
FAIL: libgomp.c++/ctor-3.C  -O0  execution test
WARNING: program timed out.
FAIL: libgomp.c++/ctor-3.C  -O1  execution test
WARNING: program timed out.
FAIL: libgomp.c++/ctor-3.C  -O2  execution test
WARNING: program timed out.
FAIL: libgomp.c++/ctor-3.C  -O3 -fomit-frame-pointer  execution test
WARNING: program timed out.
FAIL: libgomp.c++/ctor-3.C  -O3 -fomit-frame-pointer -funroll-loops  execution
test
WARNING: program timed out.
FAIL: libgomp.c++/ctor-3.C  -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions  execution test
WARNING: program timed out.
FAIL: libgomp.c++/ctor-3.C  -O3 -g  execution test
WARNING: program timed out.
FAIL: libgomp.c++/ctor-3.C  -Os  execution test
WARNING: program timed out.
FAIL: libgomp.c++/ctor-4.C  -O0  execution test
WARNING: program timed out.
FAIL: libgomp.c++/ctor-4.C  -O1  execution test
WARNING: program timed out.
FAIL: libgomp.c++/ctor-4.C  -O2  execution test
WARNING: program timed out.
FAIL: libgomp.c++/ctor-4.C  -O3 -fomit-frame-pointer  execution test
WARNING: program timed out.
FAIL: libgomp.c++/ctor-4.C  -O3 -fomit-frame-pointer -funroll-loops  execution
test
WARNING: program timed out.
FAIL: libgomp.c++/ctor-4.C  -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions  execution test
WARNING: program timed out.
FAIL: libgomp.c++/ctor-4.C  -O3 -g  execution test
WARNING: program timed out.
FAIL: libgomp.c++/ctor-4.C  -Os  execution test
WARNING: program timed out.
FAIL: libgomp.c++/ctor-6.C  -O0  execution test
WARNING: program timed out.
FAIL: libgomp.c++/ctor-6.C  -O1  execution test
WARNING: program timed out.
FAIL: libgomp.c++/ctor-6.C  -O2  execution test
WARNING: program timed out.
FAIL: libgomp.c++/ctor-6.C  -O3 -fomit-frame-pointer  execution test
WARNING: program timed out.
FAIL: libgomp.c++/ctor-6.C  -O3 -fomit-frame-pointer -funroll-loops  execution
test
WARNING: program timed out.
FAIL: libgomp.c++/ctor-6.C  -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions  execution test
WARNING: program timed out.
FAIL: libgomp.c++/ctor-6.C  -O3 -g  execution test
WARNING: program timed out.
FAIL: libgomp.c++/ctor-6.C  -Os  execution test
WARNING: program timed out.
FAIL: libgomp.c++/ctor-7.C  -O0  execution test
WARNING: program timed out.
FAIL: libgomp.c++/ctor-7.C  -O1  execution test
WARNING: program timed out.
FAIL: libgomp.c++/ctor-7.C  -O2  execution test
WARNING: program timed out.
FAIL: libgomp.c++/ctor-7.C  -O3 -fomit-frame-pointer  execution test
WARNING: program timed out.
FAIL: libgomp.c++/ctor-7.C  -O3 -fomit-frame-pointer -funroll-loops  execution
test
WARNING: program timed out.
FAIL: libgomp.c++/ctor-7.C  -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions  execution test
WARNING: program timed out.
FAIL: libgomp.c++/ctor-7.C  -O3 -g  execution test
WARNING: program timed out.
FAIL: libgomp.c++/ctor-7.C  -Os  execution test
WARNING: program timed out.
FAIL: libgomp.c++/loop-1.C  -O  execution test
WARNING: program timed out.
FAIL: libgomp.c++/loop-2.C  -O  execution test
WARNING: program timed out.
FAIL: libgomp.c++/loop-3.C  -O  execution test
WARNING: program timed out.
FAIL: libgomp.c++/loop-4.C  -O  execution test
WARNING: program timed out.
FAIL: libgomp.c++/loop-5.C  -O  execution test
WARNING: program timed out.
FAIL: libgomp.c++/loop-6.C  -O0  execution test
WARNING: program timed out.
FAIL: libgomp.c++/loop-6.C  -O1  execution test
WARNING: program timed out.
FAIL: libgomp.c++/loop-6.C  -O2  execution test
WARNING: program timed out.
FAIL: libgomp.c++/loop-6.C  -O3 -fomit-frame-pointer  execution test
WARNING: program timed out.
FAIL: libgomp.c++/loop-6.C  -O3 -fomit-frame-pointer -funroll-loops  execution
test
WARNING: program timed out.
FAIL: libgomp.c++/loop-6.C  -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions  execution test
WARNING: program timed out.
FAIL: libgomp.c++/loop-6.C  -O3 -g  execution test
WARNING: program timed out.
FAIL: libgomp.c++/loop-6.C  -Os  execution test
WARNING: program timed out.
FAIL: libgomp.c++/loop-7.C  -O0  execution test
WARNING: program timed out.
FAIL: libgomp.c++/loop-7.C  -O1  execution test
WARNING: program timed out.
FAIL: libgomp.c++/loop-7.C  -O2  execution test
WARNING: program timed out.
FAIL: libgomp.c++/loop-7.C  -O3 -fomit-frame-pointer  execution test
WARNING: program timed out.
FAIL: libgomp.c++/loop-7.C  -O3 -fomit-frame-pointer -funroll-loops  execution
test
WARNING: program timed out.
FAIL: libgomp.c++/loop-7.C  -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions  execution test
WARNING: program timed out.
FAIL: libgomp.c++/loop-7.C  -O3 -g  execution test
WARNING: program timed out.
FAIL: libgomp.c++/loop-7.C  -Os  execution test
WARNING: program timed out.
FAIL: libgomp.c++/master-1.C  -O0  execution test
WARNING: program timed out.
FAIL: libgomp.c++/master-1.C  -O1  execution test
WARNING: program timed out.
FAIL: libgomp.c++/master-1.C  -O2  execution test
WARNING: program timed out.
FAIL: libgomp.c++/master-1.C  -O3 -fomit-frame-pointer  execution test
WARNING: program timed out.
FAIL: libgomp.c++/master-1.C  -O3 -fomit-frame-pointer -funroll-loops 
execution test
WARNING: program timed out.
FAIL: libgomp.c++/master-1.C  -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions  execution test
WARNING: program timed out.
FAIL: libgomp.c++/master-1.C  -O3 -g  execution test
WARNING: program timed out.
FAIL: libgomp.c++/master-1.C  -Os  execution test
WARNING: program timed out.
FAIL: libgomp.c++/nested-1.C  -O0  execution test
WARNING: program timed out.
FAIL: libgomp.c++/nested-1.C  -O1  execution test
WARNING: program timed out.
FAIL: libgomp.c++/nested-1.C  -O2  execution test
WARNING: program timed out.
FAIL: libgomp.c++/nested-1.C  -O3 -fomit-frame-pointer  execution test
WARNING: program timed out.
FAIL: libgomp.c++/nested-1.C  -O3 -fomit-frame-pointer -funroll-loops 
execution test
WARNING: program timed out.
FAIL: libgomp.c++/nested-1.C  -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions  execution test
WARNING: program timed out.
FAIL: libgomp.c++/nested-1.C  -O3 -g  execution test
WARNING: program timed out.
FAIL: libgomp.c++/nested-1.C  -Os  execution test
WARNING: program timed out.
FAIL: libgomp.c++/parallel-1.C  -O  execution test
WARNING: program timed out.
FAIL: libgomp.c++/pr26691.C  -O  execution test
WARNING: program timed out.
FAIL: libgomp.c++/pr26943.C  -O0  execution test
WARNING: program timed out.
FAIL: libgomp.c++/pr26943.C  -O1  execution test
WARNING: program timed out.
FAIL: libgomp.c++/pr26943.C  -O2  execution test
WARNING: program timed out.
FAIL: libgomp.c++/pr26943.C  -O3 -fomit-frame-pointer  execution test
WARNING: program timed out.
FAIL: libgomp.c++/pr26943.C  -O3 -fomit-frame-pointer -funroll-loops  execution
test
WARNING: program timed out.
FAIL: libgomp.c++/pr26943.C  -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions  execution test
WARNING: program timed out.
FAIL: libgomp.c++/pr26943.C  -O3 -g  execution test
WARNING: program timed out.
FAIL: libgomp.c++/pr26943.C  -Os  execution test
WARNING: program timed out.
FAIL: libgomp.c++/pr27337.C  -O0  execution test
WARNING: program timed out.
FAIL: libgomp.c++/pr27337.C  -O1  execution test
WARNING: program timed out.
FAIL: libgomp.c++/pr27337.C  -O2  execution test
WARNING: program timed out.
FAIL: libgomp.c++/pr27337.C  -O3 -fomit-frame-pointer  execution test
WARNING: program timed out.
FAIL: libgomp.c++/pr27337.C  -O3 -fomit-frame-pointer -funroll-loops  execution
test
WARNING: program timed out.
FAIL: libgomp.c++/pr27337.C  -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions  execution test
WARNING: program timed out.
FAIL: libgomp.c++/pr27337.C  -O3 -g  execution test
WARNING: program timed out.
FAIL: libgomp.c++/pr27337.C  -Os  execution test
WARNING: program timed out.
FAIL: libgomp.c++/reduction-1.C  -O  execution test
WARNING: program timed out.
FAIL: libgomp.c++/reduction-2.C  -O  execution test
WARNING: program timed out.
FAIL: libgomp.c++/reduction-3.C  -O  execution test
WARNING: program timed out.
FAIL: libgomp.c++/sections-1.C  -O  execution test
WARNING: program timed out.
FAIL: libgomp.c++/shared-1.C  -O  execution test
WARNING: program timed out.
FAIL: libgomp.c++/shared-2.C  -O  execution test
WARNING: program timed out.
FAIL: libgomp.c++/single-1.C  -O  execution test
WARNING: program timed out.
FAIL: libgomp.c++/single-2.C  -O  execution test
WARNING: program timed out.
FAIL: libgomp.c++/single-3.C  -O  execution test

These timeouts started about three days ago.  There
weren't present at revision 116916M.  The problem isn't
present using hpux.


-- 
           Summary: Timeouts in libstdc++, libjava and libgomp testsuites
           Product: gcc
           Version: 4.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: danglin at gcc dot gnu dot org
 GCC build triplet: hppa-unknown-linux-gnu
  GCC host triplet: hppa-unknown-linux-gnu
GCC target triplet: hppa-unknown-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29118

[Bug libstdc++/29118] Timeouts in libstdc++, libjava and libgomp testsuites

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2006-09-19 05:03 -------
Does hppa-linux-gnu use dwarf2 eh info?


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Timeouts in libstdc++,      |Timeouts in libstdc++,
                   |libjava and libgomp         |libjava and libgomp
                   |testsuites                  |testsuites


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29118

[Bug middle-end/29118] [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|libstdc++                   |middle-end
           Keywords|                            |EH, wrong-code
            Summary|Timeouts in libstdc++,      |[4.2 Regression] Timeouts in
                   |libjava and libgomp         |libstdc++, libjava and
                   |testsuites                  |libgomp testsuites
   Target Milestone|---                         |4.2.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29118

[Bug middle-end/29118] [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites

[pinskia at gcc dot gnu dot org]

------- Comment #2 from pinskia at gcc dot gnu dot org  2006-09-19 05:07 -------
The patch which I am thinking might had caused this is:
2006-09-13  Andreas Krebbel  <krebbel1@de.ibm.com>

        * flow.c (calculate_global_regs_live): Invalidate eh registers
        on eh edges. Renamed invalidated_by_call to invalidated_by_eh_edge.
        (propagate_block): Handle eh registers as if they were set at basic
        block start.
        * except.c (dw2_build_landing_pads): Don't emit clobbers for eh
        registers.
        * global.c (global_conflicts): Make eh registers to conflict with
        pseudos live at basic block begin.
        * basic_block.h (bb_has_eh_pred): New function.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 GCC target triplet|hppa-unknown-linux-gnu      |hppa-*-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29118

[Bug middle-end/29118] [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca  2006-09-20 03:16 -------
Subject: Re:  [4.2 Regression] Timeouts in libstdc++, libjava and libgomp
testsuites

> The patch which I am thinking might had caused this is:
> 2006-09-13  Andreas Krebbel  <krebbel1@de.ibm.com>
> 
>         * flow.c (calculate_global_regs_live): Invalidate eh registers
>         on eh edges. Renamed invalidated_by_call to invalidated_by_eh_edge.
>         (propagate_block): Handle eh registers as if they were set at basic
>         block start.
>         * except.c (dw2_build_landing_pads): Don't emit clobbers for eh
>         registers.
>         * global.c (global_conflicts): Make eh registers to conflict with
>         pseudos live at basic block begin.
>         * basic_block.h (bb_has_eh_pred): New function.

While I could see that this might be the cause, it looks like
116942 introduced the failure.  See
<http://gcc.gnu.org/ml/gcc-testresults/2006-09/msg00983.html> and
<http://gcc.gnu.org/ml/gcc-testresults/2006-09/msg01047.html>.

Dave


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29118

[Bug middle-end/29118] [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca  2006-09-20 03:19 -------
Subject: Re:  Timeouts in libstdc++, libjava and libgomp testsuites

> Does hppa-linux-gnu use dwarf2 eh info?

It uses the dwarf2 unwind info.  So, does hpux which doesn't appear
affected.  The same exception_receiver code is generated for both.

Dave


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29118

[Bug libstdc++/29118] [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites

[pinskia at gcc dot gnu dot org]

------- 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                     |Added
----------------------------------------------------------------------------
                 CC|                            |bkoz at gcc dot gnu dot org
           Severity|normal                      |blocker
          Component|middle-end                  |libstdc++
           Keywords|EH                          |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29118

[Bug libstdc++/29118] [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites

[bkoz at gcc dot gnu dot org]

------- 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
locking code should be the same as for x86/linux. 

x86/s390/s390x/powerpc/powerpc64/ia64 all are using these code paths and look
fine. What's different about hppa?

-benjamin


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29118

[Bug libstdc++/29118] [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites

[dave at hiauly1 dot hia dot nrc dot ca]

------- 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/23591_thread-1.c is probably the easiest to debug.

I'm very busy at the moment, so the earliest I will be able to look at
this is the weekend.

> Since this is the linux target, and not the hpux target, the code paths for the
> locking code should be the same as for x86/linux. 
> 
> x86/s390/s390x/powerpc/powerpc64/ia64 all are using these code paths and look
> fine. What's different about hppa?

It's still using linuxthreads.  Also because of the limitations
of the ldcw semaphore instruction in PA 1.1, the atomic lock type
is 16 bytes and there is a dynamic alignment calculation to
select the aligned 4-byte object to use for the ldcw lock.  As
a result, there are limitations on copying/moving lock objects
that aren't present in other implementations.

NPTL is coming but its not quite ready for prime time.

Dave


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29118

[Bug libstdc++/29118] [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites

[mmitchel at gcc dot gnu dot org]

-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P5


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29118

[Bug libstdc++/29118] [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites

[bkoz at gcc dot gnu dot org]

-- 

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                     |
             Status|UNCONFIRMED                 |ASSIGNED
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2006-09-21 20:24:33
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29118

[Bug libstdc++/29118] [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites

[bkoz at gcc dot gnu 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 type
> is 16 bytes and there is a dynamic alignment calculation to
> select the aligned 4-byte object to use for the ldcw lock.  As
> a result, there are limitations on copying/moving lock objects
> that aren't present in other implementations.

Ah. This is interesting, thanks.

One thing you could try, to confirm that this is what's up, is to replace the
hppa atomics config with the generic pthreads layer.

Probably the best way to do this is to:

%mv config/cpu/hppa config/cpu/hppa.dis

blow away the build directory, and then rebuild.

During the rebuild, you should see this on the configure line:

...
configure: CPU config directory is cpu/generic
...
checking for thread model used by GCC... posix
checking for atomic builtins... no
...

To confirm, if you go into the freshly built libstdc++/src directory and

ls -al atomicity.cc

You should see it pointing to
config/cpu/generic/atomicity_mutex/atomicity.h

instead of the current 
config/cpu/hppa/atomicity.h

If you try this and run "make check-target-libstdc++-v3" and the testresults
are fine, then I can try to put in a hack for you that will bypass the current
(presumably flawed) hppa atomics config. Or, we can try to fix it to deal with
the limitations that are not present on the other linux cpu's.

best,
-benjamin


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29118

[Bug libstdc++/29118] [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites

[bkoz at gcc dot gnu dot org]

------- 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

[Bug libstdc++/29118] [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites

[dave at hiauly1 dot hia dot nrc dot ca]

------- 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 problem on hpux?

I believe they use the same atomics.  I think it points to a pthread
issue.

Dave


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29118

[Bug libstdc++/29118] [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites

[dave at hiauly1 dot hia dot nrc dot ca]

------- 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 a problem on hpux?
> 
> I believe they use the same atomics.  I think it points to a pthread
> issue.

Further to this point, I used strace to look at pthread6 while it
was executing.  I see a continuous stream of sched_yield calls with
a few nanosleep calls every so often.  Thus, I think the code is
spinning in __pthread_acquire.

This would happen if spinlock/mutex initialization is broken.  Proper
initialization is needed on hppa-linux because locked is 0 and unlocked
is 1.

Dave


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29118

[Bug libstdc++/29118] [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites

[dave at hiauly1 dot hia dot nrc dot ca]

------- 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 pthreads layer.

Doesn't fix problem.

> To confirm, if you go into the freshly built libstdc++/src directory and
> 
> ls -al atomicity.cc
> 
> You should see it pointing to
> config/cpu/generic/atomicity_mutex/atomicity.h
> 
> instead of the current 
> config/cpu/hppa/atomicity.h

Yes, atomicity.cc is pointing to the generic directory.

Dave


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29118

[Bug libstdc++/29118] [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites

[dave at hiauly1 dot hia dot nrc dot ca]

------- 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:

(gdb) break *0x40b4c6bc
Breakpoint 1 at 0x40b4c6bc: file mutex.c, line 123.
(gdb) cond 1 mutex->__m_lock.__spinlock.lock[0]==0
(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y

Starting program:
/home/dave/gcc-4.2/objdir/hppa-linux/libstdc++-v3/testsuite/23591_thread-1.xg
Error in re-setting breakpoint 1:
No symbol "mutex" in current context.
Error in re-setting breakpoint 1:
No symbol "mutex" in current context.
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 6058)]
[New Thread 32769 (LWP 6059)]
[New Thread 16386 (LWP 6060)]
[Switching to Thread 16386 (LWP 6060)]

Breakpoint 1, 0x40b4c6bc in *__GI___pthread_mutex_lock (mutex=0x41c60000)
    at mutex.c:123
123     mutex.c: No such file or directory.
        in mutex.c
(gdb) p *mutex
$1 = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0,
  __m_lock = {__spinlock = {lock = {0, 0, 0, 0}}, __status = 0}}
(gdb) bt
#0  0x40b4c6bc in *__GI___pthread_mutex_lock (mutex=0x41c60000) at mutex.c:123
#1  0x41ba9a5c in locale (this=0x41c5ece4) at gthr-default.h:549
#2  0x41ba49e4 in Init (this=<value optimized out>) at streambuf:462
#3  0x41bbea94 in __static_initialization_and_destruction_0 (
    __initialize_p=<value optimized out>, __priority=0) at iostream:77
#4  0x41c2d2c0 in __do_global_ctors_aux ()
    from
/home/dave/gcc-4.2/objdir/hppa-linux/./libstdc++-v3/src/.libs/libstdc++.so.6
#5  0x41b93984 in _init ()
    from
/home/dave/gcc-4.2/objdir/hppa-linux/./libstdc++-v3/src/.libs/libstdc++.so.6
#6  0x402917f8 in _dl_rtld_di_serinfo () from /lib/ld.so.1
#7  0x402919b0 in _dl_rtld_di_serinfo () from /lib/ld.so.1
#8  0x410710a0 in dl_open_worker (a=<value optimized out>) at dl-open.c:504
#9  0x402913a4 in _dl_rtld_di_serinfo () from /lib/ld.so.1
#10 0x410707d4 in *__GI__dl_open (file=0x10aa0 "./testsuite_shared.so",
    mode=-2147483646, caller_dlopen=0x10714, nsid=-2) at dl-open.c:577
#11 0x4037c13c in dlopen_doit (a=0x410b7608) at dlopen.c:59
#12 0x402913a4 in _dl_rtld_di_serinfo () from /lib/ld.so.1
#13 0x4037c620 in _dlerror_run (
    operate=0x41c5d458 <__cxxabiv1::__unexpected_handler+8248>,
    args=0xc025d644) at dlerror.c:162
#14 0x4037c0d0 in __dlopen (file=<value optimized out>, mode=1103486040)
    at dlopen.c:78
#15 0x00010714 in run (arg=<value optimized out>)
    at
/home/dave/gcc-4.2/gcc/libstdc++-v3/testsuite/19_diagnostics/23591_thread-1.c:35
#16 0x40b4b28c in pthread_start_thread (arg=0x410b7000) at manager.c:310
#17 0x40b4b628 in pthread_start_thread_event (arg=0x410b7000) at manager.c:334
#18 0x41036134 in thread_start () from /usr/lib/debug/libc.so.6

Dave


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29118

[Bug libstdc++/29118] [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites

[dave at hiauly1 dot hia dot nrc dot ca]

------- 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=0x41c60000)

(gdb) p locale_mutex
$2 = {_M_mutex = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0,
    __m_kind = 0, __m_lock = {__spinlock = {lock = {0, 0, 0, 0}},
    __status = 0}}}
(gdb) p &locale_mutex
$3 = (__gnu_cxx::__mutex *) 0x41c60000

All the "lock" values should be 1 immediately after initialization.

Could this be an ordering problem?

Dave


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29118

[Bug libstdc++/29118] [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites

[bkoz at gcc dot gnu dot org]

------- Comment #15 from bkoz at gcc dot gnu dot org  2006-10-06 09:48 -------
// try this simpler code.

#include <stdexcept>
#include <ext/concurrence.h>

namespace
{
  __gnu_cxx::__mutex test_mutex;
  unsigned int i;
} // anonymous namespace

void* add(void*)
{
  __gnu_cxx::__scoped_lock sentry(test_mutex);
  {
    ++i; // break here
  }
  return 0;
}

void
check_thread_create(int ret)
{
  if (ret != 0)
    {
      char buf[10];
      sprintf(buf, "%u", ret);

      std::string error("pthread_create failed: ");
      error += buf;
      error += strerror(ret);
      throw std::runtime_error(error);
    }
}

int main()
{
  pthread_t id1;
  pthread_t id2;

  check_thread_create(pthread_create(&id1, NULL, add, 0));
  check_thread_create(pthread_create(&id2, NULL, add, 0));

  pthread_join(id1, NULL);
  pthread_join(id2, NULL);

  return 0;
}


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29118

[Bug libstdc++/29118] [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites

[bkoz at gcc dot gnu dot org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1092 bytes --]



------- 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, 
      __kind = 0, __nusers = 1, {__spins = 0, __list = {__next = 0x0}}}, 
    __size =
"\001\000\000\000\000\000\000\000ý9\000\000\000\000\000\000\001\000\000\000\000\000\000",
__align = 1}}

Or, something like this (I see this on x86/linux.)

Actually, if you edit my example a bit and

void* add(void*)
{
  {
    __gnu_cxx::__scoped_lock sentry(test_mutex);
    ++i; // break here
  }
  return 0; // break here
}


On the return statement, you'll see:
(gdb) p test_mutex
$4 = {_M_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __kind = 0, 
      __nusers = 0, {__spins = 0, __list = {__next = 0x0}}}, 
    __size = '\0' <repeats 23 times>, __align = 0}}

If this is not happening, then there is something wrong with mutex usage. 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29118

[Bug libstdc++/29118] [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites

[bkoz at gcc dot gnu dot org]

------- 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 is acting so strangely. Can you try a version of
hppa-linux that is using NPTL?

best,
benjamin


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29118

[Bug libstdc++/29118] [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites

[dave at hiauly1 dot hia dot nrc dot ca]

------- 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 what your mutex should look like in gdb:

Well, we don't actually get to "break here".  The program hangs in
xactly the same way as 23591_thread-1:

(gdb) bt
#0  *__GI___pthread_mutex_lock (mutex=0x4010ee00) at mutex.c:99
#1  0x400679e4 in locale (this=0x4010dae4)
    at
/home/dave/gnu/gcc-4.2/objdir/hppa-linux/libstdc++-v3/include/hppa-linux/bits/gthr-default.h:549
#2  0x40062984 in Init (this=<value optimized out>)
    at
/home/dave/gnu/gcc-4.2/objdir/hppa-linux/libstdc++-v3/include/streambuf:462
#3  0x4007ca28 in __static_initialization_and_destruction_0 (
    __initialize_p=<value optimized out>, __priority=0)
    at
/home/dave/gnu/gcc-4.2/objdir/hppa-linux/libstdc++-v3/include/iostream:77
#4  0x400eb140 in __do_global_ctors_aux ()
    from
/home/dave/gnu/gcc-4.2/objdir/hppa-linux/./libstdc++-v3/src/.libs/libstdc++.so.6
#5  0x40051924 in _init ()
    from
/home/dave/gnu/gcc-4.2/objdir/hppa-linux/./libstdc++-v3/src/.libs/libstdc++.so.6
...
(gdb) p *mutex
$9 = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0,
__m_lock = {__spinlock = {lock = {0, 0, 0, 0}}, __status = 0}}
(gdb) p &locale_mutex
$10 = (__gnu_cxx::__mutex *) 0x4010ee00
(gdb) p mutex
$11 = (pthread_mutex_t *) 0x4010ee00

As can be seen, this occurs running constructors from _init ().  There
are several other calls to __GI___pthread_mutex_lock with properly
initialized mutexes prior to the one shown above which isn't properly
initialized.  A properly initialized mutex looks like:

(gdb) p *mutex
$13 = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0,
  __m_lock = {__spinlock = {lock = {1, 1, 1, 1}}, __status = 0}}

There are two earlier calls to __GI___pthread_mutex_lock from locale.
The first is here:

(gdb) bt
#0  *__GI___pthread_mutex_lock (mutex=0x402e1cb0) at mutex.c:99
#1  0x402ca258 in __pthread_once (once_control=0x4010dff8,
    init_routine=@0x4010bf52: 0x40067568 <std::locale::_S_initialize_once()>)
    at mutex.c:301
#2  0x40067620 in std::locale::_S_initialize ()
    at
/home/dave/gnu/gcc-4.2/objdir/hppa-linux/libstdc++-v3/include/hppa-linux/bits/gthr-default.h:516
#3  0x4006797c in locale (this=0x402e1cb0)
    at ../../../../gcc/libstdc++-v3/src/locale_init.cc:209
...

(gdb) info symbol 0x402e1cb0
once_masterlock in section .data
(gdb) p mutex
$14 = (pthread_mutex_t *) 0x402e1cb0
(gdb) p *mutex
$15 = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0,
  __m_lock = {__spinlock = {lock = {1, 1, 1, 1}}, __status = 0}}

once_masterlock appears to be statically initialized.

>From locale_init.cc:

  locale::locale() throw() : _M_impl(0)
    {
      _S_initialize();
      __gnu_cxx::__scoped_lock sentry(locale_mutex);
      _S_global->_M_add_reference();
      _M_impl = _S_global;
    }

It appears we hang at the "once_masterlock" line.  We never get to
the next line.

Dave


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29118

[Bug libstdc++/29118] [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites

[dave at hiauly1 dot hia dot nrc dot ca]

------- 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 to "break here".  The program hangs in
> xactly the same way as 23591_thread-1:

Single stepping from the entry to locale, it doesn't seem like
__mutex() is ever called for locale_mutex.

Dave


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29118

[Bug libstdc++/29118] [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites

[dave at hiauly1 dot hia dot nrc dot ca]

------- 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_initialize();".  Although a break
on the next line is never hit, I think _S_initialize() completes.

Dave


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29118

[Bug libstdc++/29118] [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites

[dave at hiauly1 dot hia dot nrc dot ca]

------- 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 might be making test_mutex static, and
> not in an anonymous namespace. 

Couldn't the constructor for locale possibly run before the one
for the locale_mutex?

Dave


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29118

[Bug libstdc++/29118] [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites

[dave at hiauly1 dot hia dot nrc dot ca]

------- 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 confirmed.  The following change allows the
test program to run successfully and gets us back to where we were
previously with respect to libstdc++ testsuite results.

At "break here", both test_mutex and locale_mutex are properly
initialized.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Index: src/locale_init.cc
===================================================================
--- src/locale_init.cc  (revision 117447)
+++ src/locale_init.cc  (working copy)
@@ -207,7 +207,6 @@
   locale::locale() throw() : _M_impl(0)
   { 
     _S_initialize();
-    __gnu_cxx::__scoped_lock sentry(locale_mutex);
     _S_global->_M_add_reference();
     _M_impl = _S_global;
   }


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29118

[Bug libstdc++/29118] [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites

[bkoz at gcc dot gnu dot org]

------- 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

[Bug libstdc++/29118] [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites

[bkoz at gcc dot gnu dot org]

------- 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 the results I'd
appreciate it.

We can't just remove the mutex in locale::locale. This rationale for this mutex
is libstdc++/12658, sadly there is no testcase in the libstdc++ testsuite to
check for this. 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29118

[Bug libstdc++/29118] [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites

[dave at hiauly1 dot hia dot nrc dot ca]

------- 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 WRT mutex initialization, and have high hopes
> for the attached patch. If you can try it, and let me know the results I'd
> appreciate it.

I rebuilt libstdc++ with the patch and ran through most of the
testsuite without seeing any timeouts.  I'm now doing a complete
bootstrap and check on a couple of systems with todays source.

Thanks,
Dave


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29118

[Bug libstdc++/29118] [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites

[bkoz at gcc dot gnu dot org]

------- 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

[Bug libstdc++/29118] [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites

[bkoz at gcc dot gnu dot org]

------- 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  <bkoz@redhat.com>

        PR libstdc++/29118
        * src/locale_init.cc (__get_locale_mutex): New. 
        (locale::locale): Use it.
        (locale::global): Use it.       


Modified:
    trunk/libstdc++-v3/ChangeLog
    trunk/libstdc++-v3/src/locale_init.cc


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29118

[Bug libstdc++/29118] [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites

[danglin at gcc dot gnu dot org]

------- 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|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29118