------- Comment #2 from danglin at gcc dot gnu dot org 2008-01-24 22:34 ------- The test fails about 1 out of 6 runs. Don't think optimization level matters.
I've been looking at two things: 1) Linking of libgomp and libgfortran shared. libc contains pthread stubs and libtool gratuitously adds -lc in shared links. We need to link libgomp against librt for sem_init, etc. librt needs real threads. If we are using real threads, we also want libgcc_s to be linked against libpthread. On head, LIB_SPEC has been recently modified to add -lpthread in the right place when -pthread is specified. However, this is all for naught as long as libtool continues to add -lc before -lgcc_s. As far as I can tell, only the first instance of a shared library in any link is used. So, a call to a function in the thread library from libgcc_s will remain unresolved if either -lc or -lpthread occurs before -lgcc_s. 2) Binding. The program never fails when linked with -static. The program fails randomly with the default deferred,nodirect binding. After hacking ltmain.sh to not add -lc and the libgomp link command to add -pthread, the program still fails. However, if I also change the binding to immediate, it doesn't fail. So, we have a problem with symbol resolution when using deferred binding. My sense is that the dynamic loader is binding the pthread functions to the stubs in libc when we use deferred binding. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28708
