[Bug fortran/44927] static linkage with -lgomp fails on simple program
--- Comment #14 from victor dot pasko at gmail dot com 2010-07-20 06:19 --- (In reply to comment #13) You clearly haven't looked at the code. Yes, I didn't look at libgfortran sources. However, I am not sure about 'terrible performance' if just two instructions (load and test) are added before every call to pthread-function. Or remove weak pthread symbols there to have thread-safety by default. But currently, namely crash occurs when -static -fopenmp are used :( And in my opinion, it's not good to not allow using -static option in GNU FORTRAN. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44927
[Bug fortran/44927] static linkage with -lgomp fails on simple program
--- Comment #12 from victor dot pasko at gmail dot com 2010-07-19 10:25
---
Isn't really difficult to fix that in libgfortran sources by using:
if(pthread_cancel)
{
pthread_cancel(...);
}
instead of just
pthread_cancel(...);
as it is now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44927
[Bug fortran/44927] static linkage with -lgomp fails on simple program
--- Comment #13 from jakub at gcc dot gnu dot org 2010-07-19 16:52 --- You clearly haven't looked at the code. libgfortran uses gthr*.h macros/inlines for portability, and those test pthread_cancel != NULL (using weak undef; test that for many different inlines, see __gthread_active_p). The problem is that if pthread_cancel is linked in from libpthread.a, but some other pthread_* function is not, then it will crash when calling that non-available function. Testing all possible pthread_* functions that are ever mentioned in gthr*.h in __gthread_active_p would be terrible for performance. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44927
[Bug fortran/44927] static linkage with -lgomp fails on simple program
--- Comment #10 from burnus at gcc dot gnu dot org 2010-07-16 07:09 --- (In reply to comment #9) (In reply to comment #6) Please don't keep reopening this bug. The symbols are weak undefs because libgfortran doesn't require (and shouldn't require) libpthread, it is thread-safe only when libpthread is linked in. After reviewing the thread (and recalling others along this line), Jakub, if you want to make the combination of -static -fopenmp a fatal error for gfortran, a patch is pre-approved. I am against it - if you properly link it, e.g. using -Wl,--whole-archive or with a POSIX Threads (pthread) library, which is linked with ld -r, it works. That's a similar issue to -m(no-)align-double: It leads to difficult to understand crashes, but it is nontrivial to diagnose properly as there are valid/working combinations - even though most combinations lead to crashes. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44927
[Bug fortran/44927] static linkage with -lgomp fails on simple program
--- Comment #11 from kargl at gcc dot gnu dot org 2010-07-16 14:48 --- (In reply to comment #10) (In reply to comment #9) (In reply to comment #6) Please don't keep reopening this bug. The symbols are weak undefs because libgfortran doesn't require (and shouldn't require) libpthread, it is thread-safe only when libpthread is linked in. After reviewing the thread (and recalling others along this line), Jakub, if you want to make the combination of -static -fopenmp a fatal error for gfortran, a patch is pre-approved. I am against it - if you properly link it, e.g. using -Wl,--whole-archive or with a POSIX Threads (pthread) library, which is linked with ld -r, it works. I don't see this in the information in the gfortran documentation. That's a similar issue to -m(no-)align-double: It leads to difficult to understand crashes, but it is nontrivial to diagnose properly as there are valid/working combinations - even though most combinations lead to crashes. Well, I would like to disable the use of -malign-double on gfortran as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44927
[Bug fortran/44927] static linkage with -lgomp fails on simple program
--- Comment #8 from victor dot pasko at gmail dot com 2010-07-16 03:55
---
You know, libgfortran works incorrectly with weak symbols from pthread :(
In case of static library it needs to call these functions only if its value is
not NULL.
So, the follwing is to be:
if(pthread_cancel)
{
pthread_cancel(...);
}
instead of just
pthread_cancel(...);
as it is now.
--
victor dot pasko at gmail dot com changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44927
[Bug fortran/44927] static linkage with -lgomp fails on simple program
--- Comment #9 from kargl at gcc dot gnu dot org 2010-07-16 04:28 --- (In reply to comment #6) Please don't keep reopening this bug. The symbols are weak undefs because libgfortran doesn't require (and shouldn't require) libpthread, it is thread-safe only when libpthread is linked in. After reviewing the thread (and recalling others along this line), Jakub, if you want to make the combination of -static -fopenmp a fatal error for gfortran, a patch is pre-approved. Something like Index: options.c === --- options.c (revision 161930) +++ options.c (working copy) @@ -390,6 +390,9 @@ gfc_post_options (const char **pfilename if (pedantic gfc_option.flag_whole_file) gfc_option.flag_whole_file = 2; + if (gfc_option.flag_openmp THE_STATIC_FLAG) +gfc_fatal_error (Conflicting options -fopenmp and -static); + gfc_cpp_post_options (); /* FIXME: return gfc_cpp_preprocess_only (); where I could not find the right flag for THE_STATIC_FLAG. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44927
[Bug fortran/44927] static linkage with -lgomp fails on simple program
--- Comment #7 from victor dot pasko at gmail dot com 2010-07-14 10:11 --- (In reply to comment #6) Please don't keep reopening this bug. Why? I disagree with your resolution. The symbols are weak undefs because libgfortran doesn't require (and shouldn't require) libpthread, it is thread-safe only when libpthread is linked in. Therefore, I don't like that libgfortran works incorrectly in this case :( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44927
[Bug fortran/44927] static linkage with -lgomp fails on simple program
--- Comment #1 from jakub at gcc dot gnu dot org 2010-07-13 09:22 --- User bug. If you link -lpthread statically (which you really shouldn't, static linking is highly not recommended), you need to ensure it is linked in as whole (i.e. -Wl,--whole-archive -lpthread -Wl,--no-whole-archive). -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44927
[Bug fortran/44927] static linkage with -lgomp fails on simple program
--- Comment #2 from victor dot pasko at gmail dot com 2010-07-13 09:27 --- OK test PASSED after adding -Wl,--whole-archive -lpthread -Wl,--no-whole-archive But there is some strange warning: % gfortran -static bug.f90 -lgomp -Wl,--whole-archive -lpthread -Wl,--no-whole-archive -lrt /usr/lib/../lib64/libpthread.a(sem_open.o): In function `sem_open': (.text+0x448): warning: the use of `mktemp' is dangerous, better use `mkstemp' vpa...@nstmklel143 /nfs/ins/proj/mkl/builds2/vpasko/10.3b1_lnx/mkl/examples/dftf % ./a.out s s 8 TEST PASS -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44927
[Bug fortran/44927] static linkage with -lgomp fails on simple program
--- Comment #3 from victor dot pasko at gmail dot com 2010-07-13 12:01 --- I would like that it was possible to get correct static program by using just: gfortran -static bug.f90 -fopenmp -- victor dot pasko at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44927
[Bug fortran/44927] static linkage with -lgomp fails on simple program
--- Comment #4 from jakub at gcc dot gnu dot org 2010-07-13 12:22 --- It is not a gcc thing though, but glibc. Some Linux distributions (e.g. recent Fedora or RHEL) ld -r all libpthread.a objects together, so this works, others do not. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44927
[Bug fortran/44927] static linkage with -lgomp fails on simple program
--- Comment #5 from victor dot pasko at gmail dot com 2010-07-13 12:36 --- The root cause of the problem is in using weak symbol pthread_cancel in unit.o object from libgfortran.a library. Why it's so? Look: % nm unit.o 04f0 T _gfortrani_close_unit 04a0 T _gfortrani_close_units U _gfortrani_error_stream 0a60 T _gfortrani_find_unit U _gfortrani_free_mem U _gfortrani_get_mem 0900 T _gfortrani_get_unit U _gfortrani_init_loop_spec 0500 T _gfortrani_init_units U _gfortrani_input_stream U _gfortrani_internal_error 0170 T _gfortrani_is_array_io 0150 T _gfortrani_is_internal_unit 0008 C _gfortrani_max_offset U _gfortrani_open_internal U _gfortrani_options U _gfortrani_output_stream B _gfortrani_unit_lock 0008 C _gfortrani_unit_root 0340 T _gfortrani_unlock_unit 0360 t close_unit_1 0040 t compare 0060 t delete_root 00d0 t delete_treap 0a50 T find_or_create_unit 0720 t find_unit_1 0180 t insert 0230 t insert_unit 0040 b internal_unit U memset w pthread_cancel w pthread_mutex_lock w pthread_mutex_trylock w pthread_mutex_unlock t rotate_left 0020 t rotate_right 0110 b unit_cache d x0.6677 -- victor dot pasko at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44927
[Bug fortran/44927] static linkage with -lgomp fails on simple program
--- Comment #6 from jakub at gcc dot gnu dot org 2010-07-13 17:08 --- Please don't keep reopening this bug. The symbols are weak undefs because libgfortran doesn't require (and shouldn't require) libpthread, it is thread-safe only when libpthread is linked in. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44927
