[Bug libstdc++/51906] New: thread lock test failures on darwin11 under Xcode 4.2

[Bug libstdc++/51906] New: thread lock test failures on darwin11 under Xcode 4.2

[howarth at nitro dot med.uc.edu]

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

             Bug #: 51906
           Summary: thread lock test failures on darwin11 under Xcode 4.2
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: howarth@nitro.med.uc.edu


Current gcc trunk exhibits a set of libstdc++ testsuite failures on darwin11
when built with Xcode 4.2.1....

WARNING: program timed out.
FAIL: 30_threads/lock/3.cc execution test
FAIL: 30_threads/recursive_mutex/try_lock/1.cc execution test
FAIL: 30_threads/try_lock/3.cc execution test

at both -m32 and -m64. These appear as...

WARNING: program timed out.
FAIL: 30_threads/lock/3.cc execution test

Assertion failed: (b), function main, file
/sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-20120117/libstdc++-v3/testsuite/30_threads/recursive_mutex/try_lock/1.cc,
line 39.FAIL: 30_threads/recursive_mutex/try_lock/1.cc execution test

Assertion failed: (result == -1), function main, file
/sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-20120117/libstdc++-v3/testsuite/30_threads/try_lock/3.cc,
line 71.
FAIL: 30_threads/try_lock/3.cc execution test

at both -m32 and -m64. Compiler built as...

COLLECT_GCC=gcc-fsf-4.7
COLLECT_LTO_WRAPPER=/sw/lib/gcc4.7/libexec/gcc/x86_64-apple-darwin11.2.0/4.7.0/lto-wrapper
Target: x86_64-apple-darwin11.2.0
Configured with: ../gcc-4.7-20120117/configure --prefix=/sw
--prefix=/sw/lib/gcc4.7 --mandir=/sw/share/man --infodir=/sw/lib/gcc4.7/info
--with-build-config=bootstrap-lto --enable-stage1-languages=c,lto
--enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw
--with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-mpc=/sw
--with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
--program-suffix=-fsf-4.7 --enable-checking=yes --enable-cloog-backend=isl
Thread model: posix
gcc version 4.7.0 20120117 (experimental) (GCC)

[Bug libstdc++/51906] thread lock test failures on darwin11 under Xcode 4.2

[redi at gcc dot gnu.org]

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 ?

[Bug libstdc++/51906] thread lock test failures on darwin11 under Xcode 4.2

[iains at gcc dot gnu.org]

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 x86_64-darwin10, but was OK @ r182620.

[Bug libstdc++/51906] thread lock test failures on darwin11 under Xcode 4.2

[howarth at nitro dot med.uc.edu]

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 existing darwin11
gcc-testresults conform to that...

r181784 shows the failures...

http://gcc.gnu.org/ml/gcc-testresults/2011-11/msg02982.html

but r180136 (prior to the PR 50196 fix commit) doesn't show these (or any)
failures in libstdc++.

http://gcc.gnu.org/ml/gcc-testresults/2011-10/msg02120.html

[Bug libstdc++/51906] thread lock test failures on darwin11 under Xcode 4.2

[dominiq at lps dot ens.fr]

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.

[Bug libstdc++/51906] thread lock test failures on darwin11 under Xcode 4.2

[redi at gcc dot gnu.org]

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 didn't fail when they didn't run  :)

prior to fixing 50196 those tests were UNSUPPORTED

[Bug libstdc++/51906] thread lock test failures on darwin11 under Xcode 4.2

[howarth at nitro dot med.uc.edu]

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 on x86_64-darwin10 with Xcode 4.2 so the problem
seems to be darwin11 specific.

[Bug libstdc++/51906] thread lock test failures on darwin11 under Xcode 4.2

[howarth at nitro dot med.uc.edu]

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
darwin10 and
then run it under darwin11 using...

setenv DYLD_LIBRARY_PATH .
setenv LD_LIBRARY_PATH .

to allow the same libgcc_s.1.dylib and libstdc++.6.dylib built on darwin10 to
be used.
the test case doesn't crash. However if I build the
30_threads/recursive_mutex/try_lock/1.cc test case
under darwin11 using -mmacosx-version-min=10.6 and run it the same way, it
crashes on both
darwin11 and darwin10.

[Bug libstdc++/51906] thread lock test failures on darwin11 under Xcode 4.2

[howarth at nitro dot med.uc.edu]

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

1) 30_threads/recursive_mutex/try_lock/1.cc compiled under darwin10 runs fine
under darwin11. Also, the darwin10 generated 1.s can be reassembled and
relinked under darwin11 and the resulting 1.exe runs fine.
2) 30_threads/recursive_mutex/try_lock/1.cc compiled under darwin11 using
-mmacosx-version-min=10.6 fails when run under either darwin11 or darwin10.
Using the 1.s generated above to reassemble and relink under darwin10 still
shows the execution failure.

[Bug libstdc++/51906] thread lock test failures on darwin11 under Xcode 4.2

[howarth at nitro dot med.uc.edu]

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   libstdc++-v3/testsuite/30_threads/try_lock/3.cc
generated with Xcode 4.2 on SL

[Bug libstdc++/51906] thread lock test failures on darwin11 under Xcode 4.2

[howarth at nitro dot med.uc.edu]

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   libstdc++-v3/testsuite/30_threads/try_lock/3.cc
generated with Xcode 4.2.1 on Lion

[Bug libstdc++/51906] thread lock test failures on darwin11 under Xcode 4.2

[howarth at nitro dot med.uc.edu]

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 either
buggy on Lion or is exposing a libstdc++ mutex bug. This usage can be seen in
libstdc++-v3/include/mutex as....

#ifdef __GTHREAD_RECURSIVE_MUTEX_INIT
    __native_type  _M_mutex = __GTHREAD_RECURSIVE_MUTEX_INIT;

    __recursive_mutex_base() = default;
#else
    __native_type  _M_mutex;

    __recursive_mutex_base()
    {
      // XXX EAGAIN, ENOMEM, EPERM, EBUSY(may), EINVAL(may)
      __GTHREAD_RECURSIVE_MUTEX_INIT_FUNCTION(&_M_mutex);
    }

    ~__recursive_mutex_base()
    { _S_destroy(&_M_mutex); }

Note that if you compile 3.ii.lion_10.6 on SL, the same execution failure is
seen there.

[Bug libstdc++/51906] thread lock test failures on darwin11 under Xcode 4.2

[howarth at nitro dot med.uc.edu]

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 
libstdc++-v3/testsuite/30_threads/try_lock/3.cc generated with Xcode 4.2 on SL
and with Xcode 4.2.1 on Lion for 10.6 API.

[Bug libstdc++/51906] thread lock test failures on darwin11 under Xcode 4.2

[redi at gcc dot gnu.org]

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 and this support is either
> buggy on Lion or is exposing a libstdc++ mutex bug.

libstdc++ really isn't doing anything complicated here, you should be able to
reproduce the problem with a minimal testcase using pthreads directly

#include <pthread.h>

struct mutex {
   pthread_mutex_t m = PTHREAD_RECURSIVE_MUTEX_INITIALIZER;
};

int main()
{
  mutex m;
  pthread_mutex_lock(&m.m);
}

It would also help to see a stack trace for where the tests hang (although I'm
guessing it's when calling pthread_mutex_lock, so I expect the code above to
have the same problem)

It's possible this is another instance of the same problem as PR 51296, i.e.
the pthreads mutex init macros are only required to work for
statically-allocated mutexes, not automatic variables.

[Bug libstdc++/51906] thread lock test failures on darwin11 under Xcode 4.2

[howarth at nitro dot med.uc.edu]

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 {
   pthread_mutex_t m;
} m ;

int main()
{

  m.m = PTHREAD_RECURSIVE_MUTEX_INITIALIZER;
  pthread_mutex_lock(&m.m);
}

I still get the compilation error...

pthread_test.c:10: error: expected expression before ‘{’ token

Also, the diff between the pthread.h in SL and Lion shows...

@@ -222,6 +223,11 @@

 #define PTHREAD_MUTEX_INITIALIZER {_PTHREAD_MUTEX_SIG_init, {0}}

+#if (!defined(_POSIX_C_SOURCE) && !defined(_XOPEN_SOURCE)) ||
defined(_DARWIN_C_SOURCE)
+#define PTHREAD_ERRORCHECK_MUTEX_INITIALIZER
{_PTHREAD_ERRORCHECK_MUTEX_SIG_init, {0}}
+#define PTHREAD_RECURSIVE_MUTEX_INITIALIZER
{_PTHREAD_RECURSIVE_MUTEX_SIG_init, {0}}
+#endif /* (!_POSIX_C_SOURCE && !_XOPEN_SOURCE) || _DARWIN_C_SOURCE */
+
 /*
  * Condition variable attributes
  */

[Bug libstdc++/51906] thread lock test failures on darwin11 under Xcode 4.2

[howarth at nitro dot med.uc.edu]

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.

[Bug libstdc++/51906] thread lock test failures on darwin11 under Xcode 4.2

[redi at gcc dot gnu.org]

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)

[Bug libstdc++/51906] thread lock test failures on darwin11 under Xcode 4.2

[redi at gcc dot gnu.org]

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.

[Bug libstdc++/51906] thread lock test failures on darwin11 under Xcode 4.2

[howarth at nitro dot med.uc.edu]

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 0x100000cd0: file
/sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-20120126/libstdc++-v3/testsuite/30_threads/try_lock/3.cc,
line 64.
(gdb) r
Starting program:
/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/x86_64-apple-darwin11.2.0/libstdc++-v3/testsuite/3.exe 
Reading symbols for shared libraries ++++........................ done

Breakpoint 1, main () at
/sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-20120126/libstdc++-v3/testsuite/30_threads/try_lock/3.cc:64
64          std::recursive_mutex m2;
(gdb) s
63          std::mutex m1;
(gdb) 
64          std::recursive_mutex m2;
(gdb) 
63          std::mutex m1;
(gdb) 
64          std::recursive_mutex m2;
(gdb) 
755        return __gthrw_(pthread_mutex_trylock) (__mutex);
(gdb) 
64          std::recursive_mutex m2;
(gdb) 
755        return __gthrw_(pthread_mutex_trylock) (__mutex);
(gdb) 
0x0000000100000e5a in dyld_stub_pthread_mutex_trylock ()
(gdb) 
Single stepping until exit from function dyld_stub_pthread_mutex_trylock, 
which has no line number information.
main () at mutex:679
679              if (__lock.owns_lock())
(gdb) 
755        return __gthrw_(pthread_mutex_trylock) (__mutex);
(gdb) 
0x0000000100000e5a in dyld_stub_pthread_mutex_trylock ()
(gdb) 
Single stepping until exit from function dyld_stub_pthread_mutex_trylock, 
which has no line number information.
0x00007fff8dde0bfb in pthread_mutex_trylock ()
(gdb) 
Single stepping until exit from function pthread_mutex_trylock, 
which has no line number information.
main () at mutex:679
679              if (__lock.owns_lock())
(gdb) 
776        return __gthrw_(pthread_mutex_unlock) (__mutex);
(gdb) 
0x0000000100000e60 in dyld_stub_pthread_mutex_unlock ()
(gdb) 
Single stepping until exit from function dyld_stub_pthread_mutex_unlock, 
which has no line number information.
main () at
/sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-20120126/libstdc++-v3/testsuite/30_threads/try_lock/3.cc:71
71          VERIFY( result == -1 );
(gdb) 
0x0000000100000e42 in dyld_stub___assert_rtn ()
(gdb) 
Single stepping until exit from function dyld_stub___assert_rtn, 
which has no line number information.
Assertion failed: (result == -1), function main, file
/sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-20120126/libstdc++-v3/testsuite/30_threads/try_lock/3.cc,
line 71.

Program received signal SIGABRT, Aborted.
0x00007fff927c182a in __kill ()
(gdb)

[Bug libstdc++/51906] thread lock test failures on darwin11 under Xcode 4.2

[iains at gcc dot gnu.org]

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

[Bug libstdc++/51906] thread lock test failures on darwin11 under Xcode 4.2

[howarth at nitro dot med.uc.edu]

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 problem) and the darwin11 build (which
exhibits it) show...

howarth% grep HAVE_AS_TLS gcc/auto-host.h
/* #undef HAVE_AS_TLS */
/* #undef HAVE_AS_TLS_MARKERS */

[Bug libstdc++/51906] thread lock test failures on darwin11 under Xcode 4.2

[redi at gcc dot gnu.org]

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: program timed out.
I didn't notice there were failed assertions too. You'll have to debug it
further yourself.
The simplest one to debug might be 30_threads/recursive_mutex/try_lock/1.cc

[Bug libstdc++/51906] thread lock test failures on darwin11 under Xcode 4.2

[howarth at nitro dot med.uc.edu]

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 this was a problem with WARNING: program timed out.
> I didn't notice there were failed assertions too. You'll have to debug it
> further yourself.
> The simplest one to debug might be 30_threads/recursive_mutex/try_lock/1.cc

I'll retry with 30_threads/recursive_mutex/try_lock/1.cc. The program time-out
was in the 30_threads/lock/3.cc execution test. The trace I gave you was from
the 30_threads/try_lock/3.cc execution test. All remember for exception
handling, etc, that darwin uses its own calls in libSystem and not those from
libgcc. Only the calls listed in libgcc_ext are used from libgcc these days.

[Bug libstdc++/51906] thread lock test failures on darwin11 under Xcode 4.2

[howarth at nitro dot med.uc.edu]

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 1 at 0x100000dcc: file
/sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-20120126/libstdc++-v3/testsuite/30_threads/recursive_mutex/try_lock/1.cc,
line 37.
(gdb) r
Starting program:
/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/x86_64-apple-darwin11.2.0/libstdc++-v3/testsuite/1.exe 
Reading symbols for shared libraries ++++........................ done

Breakpoint 1, main () at
/sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-20120126/libstdc++-v3/testsuite/30_threads/recursive_mutex/try_lock/1.cc:37
37          mutex_type m;
(gdb) s
755        return __gthrw_(pthread_mutex_trylock) (__mutex);
(gdb) 
37          mutex_type m;
(gdb) 
755        return __gthrw_(pthread_mutex_trylock) (__mutex);
(gdb) 
0x0000000100000ea4 in dyld_stub_pthread_mutex_trylock ()
(gdb) 
Single stepping until exit from function dyld_stub_pthread_mutex_trylock, 
which has no line number information.
main () at
/sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-20120126/libstdc++-v3/testsuite/30_threads/recursive_mutex/try_lock/1.cc:39
39          VERIFY( b );
(gdb) 
0x0000000100000e8c in dyld_stub___assert_rtn ()
(gdb) 
Single stepping until exit from function dyld_stub___assert_rtn, 
which has no line number information.
Assertion failed: (b), function main, file
/sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-20120126/libstdc++-v3/testsuite/30_threads/recursive_mutex/try_lock/1.cc,
line 39.

Program received signal SIGABRT, Aborted.
0x00007fff927c182a in __kill ()
(gdb) 
Single stepping until exit from function __kill, 
which has no line number information.

Program terminated with signal SIGABRT, Aborted.
The program no longer exists.

Unfortunately Apple doesn't distribute debug versions of libSystem (and I don't
know anyone outside of Apple who has managed to build those from the open
source darwin releases... although it is theoretically possible). If we need a
more detailed debug trace, I'll have to get someone at Apple to do it against
one of their libSystem debug builds of Lion.

[Bug libstdc++/51906] thread lock test failures on darwin11 under Xcode 4.2

[redi at gcc dot gnu.org]

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 shows what happens!  e.g. knowing what pthread_mutex_trylock returns
is necessary, knowing the details of what happens inside that function isn't
necessary.


What does this return?

#include <pthread.h>

struct mutex {
   pthread_mutex_t m = PTHREAD_RECURSIVE_MUTEX_INITIALIZER;
};

int main()
{
  mutex m;
  return pthread_mutex_trylock(&m.m);
}

If the solution is simply to define _XOPEN_SOURCE then that should be done for
Lion, but a relevant maintainer for that target should make that decision. 
libstdc++ relies on POSIX features so if they aren't correctly defined without
_XOPEN_SOURCE then that is needed (on GNU/Linux _GNU_SOURCE is always defined)

[Bug libstdc++/51906] thread lock test failures on darwin11 under Xcode 4.2

[howarth at nitro dot med.uc.edu]

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

/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/./gcc/g++ -shared-libgcc
-B/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/./gcc -nostdinc++
-L/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/x86_64-apple-darwin11.2.0/libstdc++-v3/src
-L/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/x86_64-apple-darwin11.2.0/libstdc++-v3/src/.libs
-B/sw/lib/gcc4.7/x86_64-apple-darwin11.2.0/bin/
-B/sw/lib/gcc4.7/x86_64-apple-darwin11.2.0/lib/ -isystem
/sw/lib/gcc4.7/x86_64-apple-darwin11.2.0/include -isystem
/sw/lib/gcc4.7/x86_64-apple-darwin11.2.0/sys-include
-B/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/x86_64-apple-darwin11.2.0/./libstdc++-v3/src/.libs
-D_GLIBCXX_ASSERT -fmessage-length=0 -ffunction-sections -fdata-sections -g -O0
 -DLOCALEDIR="." -nostdinc++
-I/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/x86_64-apple-darwin11.2.0/libstdc++-v3/include/x86_64-apple-darwin11.2.0
-I/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/x86_64-apple-darwin11.2.0/libstdc++-v3/include
-I/sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-20120126/libstdc++-v3/libsupc++
-I/sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-20120126/libstdc++-v3/include/backward
-I/sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-20120126/libstdc++-v3/testsuite/util
/sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-20120126/libstdc++-v3/testsuite/30_threads/recursive_mutex/try_lock/1.cc
-std=gnu++0x ./libtestc++.a -L/sw/lib -liconv -lm -m64 -o ./1.exe

The resulting binary fails with the same error as when compiled with -O2 but
now traces as...


(gdb) break main
Breakpoint 1 at 0x100000b8e: file
/sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-20120126/libstdc++-v3/testsuite/30_threads/recursive_mutex/try_lock/1.cc,
line 32.
(gdb) r
Starting program:
/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/x86_64-apple-darwin11.2.0/libstdc++-v3/testsuite/1.exe 
Reading symbols for shared libraries ++++........................ done

Breakpoint 1, main () at
/sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-20120126/libstdc++-v3/testsuite/30_threads/recursive_mutex/try_lock/1.cc:32
32      bool test __attribute__((unused)) = true;
(gdb) s
37          mutex_type m;
(gdb) 
38          bool b = m.try_lock();
(gdb) 
std::recursive_mutex::try_lock (this=0x7fff5fbff770) at mutex:221
221          return !__gthread_recursive_mutex_trylock(&_M_mutex);
(gdb) 
__gthread_recursive_mutex_trylock (__mutex=0x7fff5fbff770) at
x86_64-apple-darwin11.2.0/bits/gthr-default.h:813
813      return __gthread_mutex_trylock (__mutex);
(gdb) 
__gthread_mutex_trylock (__mutex=0x7fff5fbff770) at
x86_64-apple-darwin11.2.0/bits/gthr-default.h:754
754      if (__gthread_active_p ())
(gdb) 
__gthread_active_p () at x86_64-apple-darwin11.2.0/bits/gthr-default.h:306
306      return 1;
(gdb) 
307    }
(gdb) 
__gthread_mutex_trylock (__mutex=0x7fff5fbff770) at
x86_64-apple-darwin11.2.0/bits/gthr-default.h:755
755        return __gthrw_(pthread_mutex_trylock) (__mutex);
(gdb) 
758    }
(gdb) 
__gthread_recursive_mutex_trylock (__mutex=0x7fff5fbff770) at
x86_64-apple-darwin11.2.0/bits/gthr-default.h:814
814    }
(gdb) 
std::recursive_mutex::try_lock (this=0x7fff5fbff770) at mutex:222
222        }
(gdb) 
main () at
/sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-20120126/libstdc++-v3/testsuite/30_threads/recursive_mutex/try_lock/1.cc:39
39          VERIFY( b );
(gdb) 
Assertion failed: (b), function main, file
/sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-20120126/libstdc++-v3/testsuite/30_threads/recursive_mutex/try_lock/1.cc,
line 39.

Program received signal SIGABRT, Aborted.
0x00007fff927c182a in __kill ()
(gdb) 


Also, I still can't get your test program to compile with gcc 4.7 or Apple
gcc-4,2, FSF gcc 4.7 errors with...

pthread_test.c:4:22: error: expected ‘:’, ‘,’, ‘;’, ‘}’ or ‘__attribute__’
before ‘=’ token
pthread_test.c: In function ‘main’:
pthread_test.c:9:3: error: unknown type name ‘mutex’
pthread_test.c:10:34: error: request for member ‘m’ in something not a
structure or union

and Apple gcc-4.2 errors with...

pthread_test.c:4: error: expected ‘:’, ‘,’, ‘;’, ‘}’ or ‘__attribute__’ before
‘=’ token
pthread_test.c: In function ‘main’:
pthread_test.c:9: error: ‘mutex’ undeclared (first use in this function)
pthread_test.c:9: error: (Each undeclared identifier is reported only once
pthread_test.c:9: error: for each function it appears in.)
pthread_test.c:9: error: expected ‘;’ before ‘m’
pthread_test.c:10: error: ‘m’ undeclared (first use in this function)

[Bug libstdc++/51906] thread lock test failures on darwin11 under Xcode 4.2

[howarth at nitro dot med.uc.edu]

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

[Bug libstdc++/51906] thread lock test failures on darwin11 under Xcode 4.2

[redi at gcc dot gnu.org]

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 point trying that.

[Bug libstdc++/51906] thread lock test failures on darwin11 under Xcode 4.2

[howarth at nitro dot med.uc.edu]

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 which would allow you to
reproduce the compilation failure I see using...


howarth% gcc-fsf-4.7 pthread_test.i
pthread_test.c:4:22: error: expected ‘:’, ‘,’, ‘;’, ‘}’ or ‘__attribute__’
before ‘=’ token
pthread_test.c: In function ‘main’:
pthread_test.c:9:3: error: unknown type name ‘mutex’
pthread_test.c:10:34: error: request for member ‘m’ in something not a
structure or union

[Bug libstdc++/51906] thread lock test failures on darwin11 under Xcode 4.2

[redi at gcc dot gnu.org]

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.

[Bug libstdc++/51906] thread lock test failures on darwin11 under Xcode 4.2

[howarth at nitro dot med.uc.edu]

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, I was able to get...

#include <pthread.h>
#include <stdio.h>

struct mutex {
   pthread_mutex_t m = PTHREAD_RECURSIVE_MUTEX_INITIALIZER;
};

int main()
{
  mutex m;
//  return pthread_mutex_trylock(&m.m);
  printf(" returned %d\n",pthread_mutex_trylock(&m.m));

}

to compile with "g++-fsf-4.7 -std=c++0x -g -O0 pthread_test.c" on darwin11 and
it outputs "22"
which appears to be...


       The pthread_mutex_lock() and  pthread_mutex_trylock()  functions  shall
       fail if:

       EINVAL The  mutex  was  created  with the protocol attribute having the
              value PTHREAD_PRIO_PROTECT and the calling thread's priority  is
              higher than the mutex's current priority ceiling.

[Bug libstdc++/51906] thread lock test failures on darwin11 under Xcode 4.2

[redi at gcc dot gnu.org]

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  pthread_mutex_trylock()  functions  shall
>        fail if:
> 
>        EINVAL The  mutex  was  created  with the protocol attribute having the
>               value PTHREAD_PRIO_PROTECT and the calling thread's priority  is
>               higher than the mutex's current priority ceiling.

That's the POSIX spec, but priorities don't apply to that test. The Mac OS X
pthread_mutex_trylock(3) man page (which doesn't seem to have been updated
since it was copied from BSD) says simply

     [EINVAL]           The value specified by mutex is invalid.

and the pthread(3) man page says "The default system libraries include pthread
functions.  No additional libraries or CFLAGS are necessary to use this API"
which isn't true if _XOPEN_SOURCE is needed.

[Bug libstdc++/51906] thread lock test failures on darwin11 under Xcode 4.2

[howarth at nitro dot med.uc.edu]

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://ptgmedia.pearsoncmg.com/images/0201633922/sourcecode/errors.h

compiles fine with "g++-fsf-4.7 -std=c++0x -g -O0 trylock.c" and executes
without
errors on darwin11.

[Bug libstdc++/51906] thread lock test failures on darwin11 under Xcode 4.2

[redi at gcc dot gnu.org]

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
info you've given it seems that all the failures relate to recursive mutexes.)

[Bug libstdc++/51906] thread lock test failures on darwin11 under Xcode 4.2

[redi at gcc dot gnu.org]

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 reconfirmed|                            |2012-02-01
         AssignedTo|unassigned at gcc dot       |redi at gcc dot gnu.org
                   |gnu.org                     |
   Target Milestone|---                         |4.7.0
     Ever Confirmed|0                           |1

--- Comment #35 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-02-01 11:01:12 UTC ---
(In reply to comment #34)
> A recursive mutex using pthread_mutex_init() works.

Thanks for the analysis.

I'm going to add some extra preprocessor conditions around the __mutex_base and
__recursive_mutex_base initialization so that target maintainers can force use
of the pthread_mutex_init function on an OS-by-OS basis.  That should allow
this issue to be fixed for Lion and PR 51296 to be fixed for Tru64.

[Bug libstdc++/51906] thread lock test failures on darwin11 under Xcode 4.2

[redi at gcc dot gnu.org]

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

[Bug libstdc++/51906] thread lock test failures on darwin11 under Xcode 4.2

[howarth at nitro dot med.uc.edu]

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 and users will have a working
> version?

You would probably have to use Availability.h and something like...

        #ifdef __MAC_OS_X_VERSION_MIN_REQUIRED
            // code only compiled when targeting Mac OS X and not iPhone
            // note use of 1070 instead of __MAC_10_7
            #if __MAC_OS_X_VERSION_MIN_REQUIRED == 1070
                // code in here to run targeting Lion
            #else
                // code here can assume targeting pre- or post-Lion.
            #endif
        #endif

[Bug libstdc++/51906] thread lock test failures on darwin11 under Xcode 4.2

[howarth at nitro dot med.uc.edu]

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 (!defined(_POSIX_C_SOURCE) && !defined(_XOPEN_SOURCE)) ||
defined(_DARWIN_C_SOURCE)
#define PTHREAD_ERRORCHECK_MUTEX_INITIALIZER
{_PTHREAD_ERRORCHECK_MUTEX_SIG_init, {0}}
#define PTHREAD_RECURSIVE_MUTEX_INITIALIZER {_PTHREAD_RECURSIVE_MUTEX_SIG_init,
{0}}
#endif /* (!_POSIX_C_SOURCE && !_XOPEN_SOURCE) || _DARWIN_C_SOURCE */

regardless of MACOSX_DEPLOYMENT_TARGET. This actually seems like another Apple
bug to me since there really should be a wrapper like...

        #ifdef __MAC_OS_X_VERSION_MIN_REQUIRED
            // code only compiled when targeting Mac OS X and not iPhone
            // note use of 1070 instead of __MAC_10_7
            #if __MAC_OS_X_VERSION_MIN_REQUIRED >= 1070
                // code in here to run targeting Lion
            #else
                // code here can assume targeting pre-Lion.
            #endif
        #endif

I think we really have to unconditionally initialize the mutex on darwin.

[Bug libstdc++/51906] thread lock test failures on darwin11 under Xcode 4.2

[iains at gcc dot gnu.org]

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 undesirable).

Use the " __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__" macro - which is
provided by GCC and  clang for all versions that produce OSX code (I would
imagine that any compiler would need to implement it - since the system headers
depend on it heavily).

thus:

#if defined (__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__) \
     && (__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ >= 1070) \
/* &&  (__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ < fixed-version) */

 ... code for buggy Lion ...

#else

... the rest

#endif

[Bug libstdc++/51906] thread lock test failures on darwin11 under Xcode 4.2

[redi at gcc dot gnu.org]

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 thinking of something like this, which allows os_defines.h to set a macro
which forces gthreads to use the init function if the macro is known to be
problematic.  This should work for PR 51296 too

[Bug libstdc++/51906] thread lock test failures on darwin11 under Xcode 4.2

[iains at gcc dot gnu.org]

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 like this, which allows os_defines.h to set a macro
> which forces gthreads to use the init function if the macro is known to be
> problematic.  This should work for PR 51296 too


+#if __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ == 1070
+# define _GTHREAD_USE_RECURSIVE_MUTEX_INIT_FUNC
+#endif

unless the header is guaranteed only to be included for Darwin, then I'd guard
with a
 defined (__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__)

Hmm.. if we use >= then we don't need to keep amending when new OS Versions are
sent out - we're already at 1073 AFAIK.  OTOH, it means that someone needs to
keep an eye on when the fix is made and adjust this code then.

Don't have Lion here (yet) to test it, sorry.

[Bug libstdc++/51906] thread lock test failures on darwin11 under Xcode 4.2

[redi at gcc dot gnu.org]

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
libstdc++-v3/config/os/bsd/darwin/os_defines.h

[Bug libstdc++/51906] thread lock test failures on darwin11 under Xcode 4.2

[howarth at nitro dot med.uc.edu]

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
> libstdc++-v3/config/os/bsd/darwin/os_defines.h

While this appears to work for the generic testsuite run, breakage can still be
exposed by appending...

-mmacosx-version-min=10.6

to the compilation line for 30_threads/lock/3.cc  etc. I expected this problem
because the proposed fix doesn't handle the situation of targeting 10.6 on
Lion. I complained about this on darwin-dev earlier today...

http://lists.apple.com/archives/darwin-dev/2012/Feb/msg00009.html

but the darwin developers seem strangely unbothered by different OS releases
producing different code for the same target OS release.

http://lists.apple.com/archives/darwin-dev/2012/Feb/msg00011.html

[Bug libstdc++/51906] thread lock test failures on darwin11 under Xcode 4.2

[iains at gcc dot gnu.org]

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 the OS bug.

If you are saying:
code targeted at 10.6 produced on 10.7 (using the correct 10.6 SDK) doesn't run
properly on 10.6, then that is something that people should be concerned about.

[Bug libstdc++/51906] thread lock test failures on darwin11 under Xcode 4.2

[redi at gcc dot gnu.org]

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 macro if
MIN_REQUIRED >= 1080 since we know that it won't be run on a system where the
bug is present.

[Bug libstdc++/51906] thread lock test failures on darwin11 under Xcode 4.2

[iains at gcc dot gnu.org]

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 -mmacosx-version-min=10.6 - will cause the macro value to be 1060 - so
defeating it.  One would not expect it to run on 10.7.

If one puts -mmacosx-version-min=10.6  and sysroots to the 10.6 SDK - *and*
then transfers the executable to a 10.6 system - then that should work.  If
not, then I agree.

> If the bug is later fixed in (say) 10.8 then we could use the init macro if
> MIN_REQUIRED >= 1080 since we know that it won't be run on a system where the
> bug is present.

Indeed.. let's hope its 107x rather than 1080 ...

[Bug libstdc++/51906] thread lock test failures on darwin11 under Xcode 4.2

[howarth at nitro dot med.uc.edu]

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.
> 
> I hope not.
> putting -mmacosx-version-min=10.6 - will cause the macro value to be 1060 - so
> defeating it.  One would not expect it to run on 10.7.
> 
> If one puts -mmacosx-version-min=10.6  and sysroots to the 10.6 SDK - *and*
> then transfers the executable to a 10.6 system - then that should work.  If
> not, then I agree.

Okay. If we are assuming that -mmacosx-version-min=10.6 also requires a sys
root to the 10.6 SDK
then the patch would be okay. I still think Apple made a mistake in the 10.7
SDK to not protect the definitions for PTHREAD_ERRORCHECK_MUTEX_INITIALIZER and
PTHREAD_RECURSIVE_MUTEX_INITIALIZER from not being defined for < 10.7.

> 
> > If the bug is later fixed in (say) 10.8 then we could use the init macro if
> > MIN_REQUIRED >= 1080 since we know that it won't be run on a system where the
> > bug is present.
> 
> Indeed.. let's hope its 107x rather than 1080 ...

[Bug libstdc++/51906] thread lock test failures on darwin11 under Xcode 4.2

[howarth at nitro dot med.uc.edu]

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

/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/./gcc/g++ -shared-libgcc
-B/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/./gcc -nostdinc++
-L/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/x86_64-apple-darwin11.3.0/libstdc++-v3/src
-L/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/x86_64-apple-darwin11.3.0/libstdc++-v3/src/.libs
-B/sw/lib/gcc4.7/x86_64-apple-darwin11.3.0/bin/
-B/sw/lib/gcc4.7/x86_64-apple-darwin11.3.0/lib/ -isystem
/sw/lib/gcc4.7/x86_64-apple-darwin11.3.0/include -isystem
/sw/lib/gcc4.7/x86_64-apple-darwin11.3.0/sys-include
-B/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/x86_64-apple-darwin11.3.0/./libstdc++-v3/src/.libs
-g -O2 -D_GLIBCXX_ASSERT -fmessage-length=0 -ffunction-sections -fdata-sections
-g -O2 -g -O2 -DLOCALEDIR="." -nostdinc++
-I/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/x86_64-apple-darwin11.3.0/libstdc++-v3/include/x86_64-apple-darwin11.3.0
-I/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/x86_64-apple-darwin11.3.0/libstdc++-v3/include
-I/sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-20120203/libstdc++-v3/libsupc++
-I/sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-20120203/libstdc++-v3/include/backward
-I/sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-20120203/libstdc++-v3/testsuite/util
/sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-20120203/libstdc++-v3/testsuite/30_threads/mutex/try_lock/1.cc
-std=gnu++0x ./libtestc++.a -L/sw/lib -liconv -lm -m64 -o ./1.exe
-mmacosx-version-min=10.6 --sysroot=/Developer/SDKs/MacOSX10.6.sdk
In file included from
/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/x86_64-apple-darwin11.3.0/libstdc++-v3/include/system_error:39:0,
                 from
/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/x86_64-apple-darwin11.3.0/libstdc++-v3/include/mutex:44,
                 from
/sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-20120203/libstdc++-v3/testsuite/30_threads/mutex/try_lock/1.cc:26:
/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/x86_64-apple-darwin11.3.0/libstdc++-v3/include/x86_64-apple-darwin11.3.0/bits/error_constants.h:135:24:
error: ‘EOWNERDEAD’ was not declared in this scope
/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/x86_64-apple-darwin11.3.0/libstdc++-v3/include/x86_64-apple-darwin11.3.0/bits/error_constants.h:151:34:
error: ‘ENOTRECOVERABLE’ was not declared in this scope

[Bug libstdc++/51906] thread lock test failures on darwin11 under Xcode 4.2

[redi at gcc dot gnu.org]

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 hope not.
> putting -mmacosx-version-min=10.6 - will cause the macro value to be 1060 - so
> defeating it.  One would not expect it to run on 10.7.

So using -mmacosx-version-min=10.6 without also using the 10.6 SDK is pilot
error?

But if I understand correctly, 10.6 didn't define
PTHREAD_MUTEX_RECURSIVE_INITIALIZER anyway, so using the 10.6 SDK would cause
it to be undefined, so why not just disable __GTHREAD_RECURSIVE_MUTEX_INIT
unconditionally?

The only system that defines it (10.7) can't use it.

> If one puts -mmacosx-version-min=10.6  and sysroots to the 10.6 SDK - *and*
> then transfers the executable to a 10.6 system - then that should work.  If
> not, then I agree.

Presumably it doesn't even need to be transferred to a 10.6 system, using the
10.6 SDK should mean the headers don't have the static initializer, so the
pthread_mutex_init_function() will always be used to create a recursive mutex,
and Greg says that works on 10.7

[Bug libstdc++/51906] thread lock test failures on darwin11 under Xcode 4.2

[redi at gcc dot gnu.org]

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 you end up with the
> error...

Please file a separate bug for that.

This is just another example of libstdc++ assuming that the environment it sees
at configure time is the same as it will see when being used.

[Bug libstdc++/51906] thread lock test failures on darwin11 under Xcode 4.2

[iains at gcc dot gnu.org]

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 unconditionally
> > > on darwin.
> > 
> > I hope not.
> > putting -mmacosx-version-min=10.6 - will cause the macro value to be 1060 - so
> > defeating it.  One would not expect it to run on 10.7.
> 
> So using -mmacosx-version-min=10.6 without also using the 10.6 SDK is pilot
> error?

if you are relying on system features that are not the same on different
versions, then yes.

> But if I understand correctly, 10.6 didn't define
> PTHREAD_MUTEX_RECURSIVE_INITIALIZER anyway, so using the 10.6 SDK would cause
> it to be undefined, so why not just disable __GTHREAD_RECURSIVE_MUTEX_INIT
> unconditionally?
> 
> The only system that defines it (10.7) can't use it.

OK. I'd missed that - in which case no objection to the unconditional disable
from me.

> > If one puts -mmacosx-version-min=10.6  and sysroots to the 10.6 SDK - *and*
> > then transfers the executable to a 10.6 system - then that should work.  If
> > not, then I agree.
> 
> Presumably it doesn't even need to be transferred to a 10.6 system, using the
> 10.6 SDK should mean the headers don't have the static initializer, so the
> pthread_mutex_init_function() will always be used to create a recursive mutex,
> and Greg says that works on 10.7

Well, in this case you would bypass your test, but use the older header
(notwithstanding issues of run-time vs config time) - so, yes, I suppose it
would work in principle.

[Bug libstdc++/51906] thread lock test failures on darwin11 under Xcode 4.2

[mikestump at comcast dot net]

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 such...  I think
that is a good way forward.  If they would fix it in a .x minor OS release, I'm
fine with simply requiring the user update their system as well, though, I
wouldn't holds ones breath for the update.

[Bug libstdc++/51906] thread lock test failures on darwin11 under Xcode 4.2

[redi at gcc dot gnu.org]

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 equivalent to stop libstdc++ using it.

I'll try to work on a final version of the patch today.

[Bug libstdc++/51906] thread lock test failures on darwin11 under Xcode 4.2

[redi at gcc dot gnu.org]

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=gcc&view=rev&rev=183955
Log:
libgcc/

    PR libstdc++/51296
    PR libstdc++/51906
    * gthr-posix.h: Allow static initializer macros to be disabled.
    (__gthrw_pthread_cond_init): Define weak reference unconditionally.

libstdc++-v3/

    PR libstdc++/51296
    * include/std/mutex (__mutex_base::~__mutex_base): Declare noexcept.
    * src/c++11/condition_variable.cc (condition_variable): Use macro for
    initializer function.

    PR libstdc++/51906
    * config/os/bsd/darwin/os_defines.h: Disable static initializer for
    recursive mutexes.

Modified:
    trunk/libgcc/ChangeLog
    trunk/libgcc/gthr-posix.h
    trunk/libstdc++-v3/ChangeLog
    trunk/libstdc++-v3/config/os/bsd/darwin/os_defines.h
    trunk/libstdc++-v3/include/std/mutex
    trunk/libstdc++-v3/src/c++11/condition_variable.cc

[Bug libstdc++/51906] thread lock test failures on darwin11 under Xcode 4.2

[redi at gcc dot gnu.org]

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

[Bug libstdc++/51906] thread lock test failures on darwin11 under Xcode 4.2

[howarth at nitro dot med.uc.edu]

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

--- Comment #56 from Jack Howarth <howarth at nitro dot med.uc.edu> 2012-02-07 18:34:35 UTC ---
Confirmed fixed at r183971 ...

        === libstdc++ tests ===


Running target unix/-m32

        === libstdc++ Summary for unix/-m32 ===

# of expected passes        7785
# of expected failures        43
# of unsupported tests        572

Running target unix/-m64

        === libstdc++ Summary for unix/-m64 ===

# of expected passes        7783
# of expected failures        43
# of unsupported tests        573

        === libstdc++ Summary ===

# of expected passes        15568
# of expected failures        86
# of unsupported tests        1145

Compiler version: gcc libstdc++ 
Platform: x86_64-apple-darwin11.3.0
configure flags: --prefix=/sw --prefix=/sw/lib/gcc4.7 --mandir=/sw/share/man
--infodir=/sw/lib/gcc4.7/info --with-build-config=bootstrap-lto
--enable-stage1-languages=c,lto
--enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw
--with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-mpc=/sw
--with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
--program-suffix=-fsf-4.7 --enable-checking=release --enable-cloog-backend=isl

[Bug libstdc++/51906] thread lock test failures on darwin11 under Xcode 4.2

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906

--- Comment #57 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Iain D Sandoe <iains@gcc.gnu.org>:

https://gcc.gnu.org/g:a044c9d25972b22c6b4c8ec27f2de5fd622573cc

commit r13-4482-ga044c9d25972b22c6b4c8ec27f2de5fd622573cc
Author: Iain Sandoe <iain@sandoe.co.uk>
Date:   Sat Dec 3 17:09:35 2022 +0000

    libstdc++, Darwin: Limit recursive mutex init to OS versions needing it.

    The problem described in pr 51906 was fixed in the next OS release.  Limit
the
    workaround to systems that need it.

    Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>

    libstdc++-v3/ChangeLog:

            * config/os/bsd/darwin/os_defines.h
            (_GTHREAD_USE_RECURSIVE_MUTEX_INIT_FUNC): Limit use of this macro
            to OS versions that need it.

[Bug libstdc++/51906] thread lock test failures on darwin11 under Xcode 4.2

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906

--- Comment #58 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-12 branch has been updated by Iain D Sandoe
<iains@gcc.gnu.org>:

https://gcc.gnu.org/g:ab4ff3e9fe881ef85a8156f2be528872c6a2fdfc

commit r12-10336-gab4ff3e9fe881ef85a8156f2be528872c6a2fdfc
Author: Iain Sandoe <iain@sandoe.co.uk>
Date:   Sat Dec 3 17:09:35 2022 +0000

    libstdc++, Darwin: Limit recursive mutex init to OS versions needing it.

    The problem described in pr 51906 was fixed in the next OS release.  Limit
the
    workaround to systems that need it.

    Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>

    libstdc++-v3/ChangeLog:

            * config/os/bsd/darwin/os_defines.h
            (_GTHREAD_USE_RECURSIVE_MUTEX_INIT_FUNC): Limit use of this macro
            to OS versions that need it.

    (cherry picked from commit a044c9d25972b22c6b4c8ec27f2de5fd622573cc)

[Bug libstdc++/51906] thread lock test failures on darwin11 under Xcode 4.2

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906

--- Comment #59 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Iain D Sandoe
<iains@gcc.gnu.org>:

https://gcc.gnu.org/g:17212f5912d8f57b3757633444ae64c9831aa8f7

commit r11-11356-g17212f5912d8f57b3757633444ae64c9831aa8f7
Author: Iain Sandoe <iain@sandoe.co.uk>
Date:   Sat Dec 3 17:09:35 2022 +0000

    libstdc++, Darwin: Limit recursive mutex init to OS versions needing it.

    The problem described in pr 51906 was fixed in the next OS release.  Limit
the
    workaround to systems that need it.

    Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>

    libstdc++-v3/ChangeLog:

            * config/os/bsd/darwin/os_defines.h
            (_GTHREAD_USE_RECURSIVE_MUTEX_INIT_FUNC): Limit use of this macro
            to OS versions that need it.

    (cherry picked from commit a044c9d25972b22c6b4c8ec27f2de5fd622573cc)