[Bug libgomp/28708] FAIL: libgomp.fortran/vla6.f90 -O0 execution test

["danglin at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>]

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