Bug 51906 - thread lock test failures on darwin11 under Xcode 4.2
Summary: thread lock test failures on darwin11 under Xcode 4.2
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: libstdc++ (show other bugs)
Version: 4.7.0
: P3 normal
Target Milestone: 4.7.0
Assignee: Jonathan Wakely
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-01-19 19:48 UTC by Jack Howarth
Modified: 2012-02-07 18:34 UTC (History)
3 users (show)

See Also:
Host: x86_64-apple-darwin11
Target: x86_64-apple-darwin11
Build: x86_64-apple-darwin11
Known to work:
Known to fail:
Last reconfirmed: 2012-02-01 00:00:00


Attachments
preprocessed source for libstdc++-v3/testsuite/30_threads/try_lock/3.cc generated with Xcode 4.2 on SL (73.63 KB, text/plain)
2012-01-28 16:47 UTC, Jack Howarth
Details
preprocessed source for libstdc++-v3/testsuite/30_threads/try_lock/3.cc generated with Xcode 4.2.1 on Lion (74.01 KB, text/plain)
2012-01-28 16:48 UTC, Jack Howarth
Details
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. (22.28 KB, text/plain)
2012-01-28 16:49 UTC, Jack Howarth
Details
preprocessed source from FSF gcc 4.7 for pthread test code (2.62 KB, text/plain)
2012-01-31 01:05 UTC, Jack Howarth
Details
disable __GTHREAD_RECURSIVE_MUTEX_INIT for Lion (853 bytes, patch)
2012-02-03 08:46 UTC, Jonathan Wakely
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jack Howarth 2012-01-19 19:48:07 UTC
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)
Comment 1 Jonathan Wakely 2012-01-19 19:58:04 UTC
have they been failing since I enabled them by fixing PR 50196 ?
Comment 2 Iain Sandoe 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.
Comment 3 Jack Howarth 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
Comment 4 Dominique d'Humieres 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.
Comment 5 Jonathan Wakely 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
Comment 6 Jack Howarth 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.
Comment 7 Jack Howarth 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.
Comment 8 Jack Howarth 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.
Comment 9 Jack Howarth 2012-01-28 16:47:49 UTC
Created attachment 26490 [details]
preprocessed source for   libstdc++-v3/testsuite/30_threads/try_lock/3.cc generated with Xcode 4.2 on SL
Comment 10 Jack Howarth 2012-01-28 16:48:37 UTC
Created attachment 26491 [details]
preprocessed source for   libstdc++-v3/testsuite/30_threads/try_lock/3.cc generated with Xcode 4.2.1 on Lion
Comment 11 Jack Howarth 2012-01-28 16:49:14 UTC
Created attachment 26492 [details]
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.
Comment 12 Jack Howarth 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.
Comment 13 Jonathan Wakely 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.
Comment 14 Jack Howarth 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
  */
Comment 15 Jack Howarth 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.
Comment 16 Jonathan Wakely 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)
Comment 17 Jonathan Wakely 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.
Comment 18 Jack Howarth 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)
Comment 19 Iain Sandoe 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
Comment 20 Jack Howarth 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 */
Comment 21 Jonathan Wakely 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
Comment 22 Jack Howarth 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.
Comment 23 Jack Howarth 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.
Comment 24 Jonathan Wakely 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)
Comment 25 Jack Howarth 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)
Comment 26 Jack Howarth 2012-01-31 01:05:15 UTC
Created attachment 26525 [details]
preprocessed source from FSF gcc 4.7 for pthread test code
Comment 27 Jack Howarth 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
Comment 28 Jonathan Wakely 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.
Comment 29 Jonathan Wakely 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.
Comment 30 Jack Howarth 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.
Comment 31 Jonathan Wakely 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.
Comment 32 Jack Howarth 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.
Comment 33 Jonathan Wakely 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.)
Comment 34 Greg Parker 2012-01-31 22:19:56 UTC
There's an OS X bug here. The problem is that pthread_mutex_trylock() does not recognize PTHREAD_RECURSIVE_MUTEX_INITIALIZER. If you use that static initializer and the first operation on the mutex is pthread_mutex_trylock() then it will fail with EINVAL.

A recursive mutex using pthread_mutex_init() works. A recursive mutex for which the first operation is pthread_mutex_lock() also works.

I filed rdar://10784745 in Apple's bug reporter.
Comment 35 Jonathan Wakely 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.
Comment 36 Jonathan Wakely 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?
Comment 37 Jack Howarth 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
Comment 38 Jack Howarth 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.
Comment 39 Iain Sandoe 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
Comment 40 Jonathan Wakely 2012-02-03 08:46:20 UTC
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
Comment 41 Iain Sandoe 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.
Comment 42 Jonathan Wakely 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
Comment 43 Jack Howarth 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
Comment 44 Iain Sandoe 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.
Comment 45 Jonathan Wakely 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.
Comment 46 Iain Sandoe 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 ...
Comment 47 Jack Howarth 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 ...
Comment 48 Jack Howarth 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
Comment 49 Jonathan Wakely 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
Comment 50 Jonathan Wakely 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.
Comment 51 Iain Sandoe 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.
Comment 52 Mike Stump 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.
Comment 53 Jonathan Wakely 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.
Comment 54 Jonathan Wakely 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
Comment 55 Jonathan Wakely 2012-02-07 09:21:13 UTC
this should be fixed now - I won't close it until someone can verify it on darwin
Comment 56 Jack Howarth 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