public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/44927] New: static linkage with -lgomp fails on simple program
@ 2010-07-13 8:41 victor dot pasko at gmail dot com
2010-07-13 9:22 ` [Bug fortran/44927] " jakub at gcc dot gnu dot org
` (13 more replies)
0 siblings, 14 replies; 15+ messages in thread
From: victor dot pasko at gmail dot com @ 2010-07-13 8:41 UTC (permalink / raw)
To: gcc-bugs
gfortran -static bug.f90 -lgomp -lpthread -lrt
./a.out << EOF
-static@omp_get_max_threads
EOF
#0 0x0000000000000000 in ?? ()
#1 0x000000000040e345 in get_external_unit (n=5, do_create=1) at
/export/users/aagafono/gnu_4.5.0/gcc-4.5.0/libgfortran/../gcc/gthr-posix.h:767
#2 0x000000000040cecf in data_transfer_init (dtp=0x7fffdd077520, read_flag=1)
at /export/users/aagafono/gnu_4.5.0/gcc-4.5.0/libgfortran/io/transfer.c:2133
#3 0x00000000004002e7 in MAIN__ ()
#4 0x000000000040047d in main ()
% cat bug.f90
program gompBUGonSTATIClinkagewithGNUfortran
integer omp_get_max_threads
integer n
character*32 buf
read *, buf
n = omp_get_max_threads()
print *, buf
print *, n
print *, 'TEST PASS'
end
--
Summary: static linkage with -lgomp fails on simple program
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: victor dot pasko at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44927
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug fortran/44927] static linkage with -lgomp fails on simple program
2010-07-13 8:41 [Bug fortran/44927] New: static linkage with -lgomp fails on simple program victor dot pasko at gmail dot com
@ 2010-07-13 9:22 ` jakub at gcc dot gnu dot org
2010-07-13 9:27 ` victor dot pasko at gmail dot com
` (12 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: jakub at gcc dot gnu dot org @ 2010-07-13 9:22 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug fortran/44927] static linkage with -lgomp fails on simple program
2010-07-13 8:41 [Bug fortran/44927] New: static linkage with -lgomp fails on simple program victor dot pasko at gmail dot com
2010-07-13 9:22 ` [Bug fortran/44927] " jakub at gcc dot gnu dot org
@ 2010-07-13 9:27 ` victor dot pasko at gmail dot com
2010-07-13 12:01 ` victor dot pasko at gmail dot com
` (11 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: victor dot pasko at gmail dot com @ 2010-07-13 9:27 UTC (permalink / raw)
To: gcc-bugs
------- 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'
vpasko@nstmklel143
/nfs/ins/proj/mkl/builds2/vpasko/10.3b1_lnx/mkl/examples/dftf
% ./a.out
sssss
sssss
8
TEST PASS
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44927
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug fortran/44927] static linkage with -lgomp fails on simple program
2010-07-13 8:41 [Bug fortran/44927] New: static linkage with -lgomp fails on simple program victor dot pasko at gmail dot com
2010-07-13 9:22 ` [Bug fortran/44927] " jakub at gcc dot gnu dot org
2010-07-13 9:27 ` victor dot pasko at gmail dot com
@ 2010-07-13 12:01 ` victor dot pasko at gmail dot com
2010-07-13 12:23 ` jakub at gcc dot gnu dot org
` (10 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: victor dot pasko at gmail dot com @ 2010-07-13 12:01 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug fortran/44927] static linkage with -lgomp fails on simple program
2010-07-13 8:41 [Bug fortran/44927] New: static linkage with -lgomp fails on simple program victor dot pasko at gmail dot com
` (2 preceding siblings ...)
2010-07-13 12:01 ` victor dot pasko at gmail dot com
@ 2010-07-13 12:23 ` jakub at gcc dot gnu dot org
2010-07-13 12:37 ` victor dot pasko at gmail dot com
` (9 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: jakub at gcc dot gnu dot org @ 2010-07-13 12:23 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug fortran/44927] static linkage with -lgomp fails on simple program
2010-07-13 8:41 [Bug fortran/44927] New: static linkage with -lgomp fails on simple program victor dot pasko at gmail dot com
` (3 preceding siblings ...)
2010-07-13 12:23 ` jakub at gcc dot gnu dot org
@ 2010-07-13 12:37 ` victor dot pasko at gmail dot com
2010-07-13 17:08 ` jakub at gcc dot gnu dot org
` (8 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: victor dot pasko at gmail dot com @ 2010-07-13 12:37 UTC (permalink / raw)
To: gcc-bugs
------- 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
00000000000004f0 T _gfortrani_close_unit
00000000000004a0 T _gfortrani_close_units
U _gfortrani_error_stream
0000000000000a60 T _gfortrani_find_unit
U _gfortrani_free_mem
U _gfortrani_get_mem
0000000000000900 T _gfortrani_get_unit
U _gfortrani_init_loop_spec
0000000000000500 T _gfortrani_init_units
U _gfortrani_input_stream
U _gfortrani_internal_error
0000000000000170 T _gfortrani_is_array_io
0000000000000150 T _gfortrani_is_internal_unit
0000000000000008 C _gfortrani_max_offset
U _gfortrani_open_internal
U _gfortrani_options
U _gfortrani_output_stream
0000000000000000 B _gfortrani_unit_lock
0000000000000008 C _gfortrani_unit_root
0000000000000340 T _gfortrani_unlock_unit
0000000000000360 t close_unit_1
0000000000000040 t compare
0000000000000060 t delete_root
00000000000000d0 t delete_treap
0000000000000a50 T find_or_create_unit
0000000000000720 t find_unit_1
0000000000000180 t insert
0000000000000230 t insert_unit
0000000000000040 b internal_unit
U memset
w pthread_cancel
w pthread_mutex_lock
w pthread_mutex_trylock
w pthread_mutex_unlock
0000000000000000 t rotate_left
0000000000000020 t rotate_right
0000000000000110 b unit_cache
0000000000000000 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
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug fortran/44927] static linkage with -lgomp fails on simple program
2010-07-13 8:41 [Bug fortran/44927] New: static linkage with -lgomp fails on simple program victor dot pasko at gmail dot com
` (4 preceding siblings ...)
2010-07-13 12:37 ` victor dot pasko at gmail dot com
@ 2010-07-13 17:08 ` jakub at gcc dot gnu dot org
2010-07-14 10:11 ` victor dot pasko at gmail dot com
` (7 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: jakub at gcc dot gnu dot org @ 2010-07-13 17:08 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug fortran/44927] static linkage with -lgomp fails on simple program
2010-07-13 8:41 [Bug fortran/44927] New: static linkage with -lgomp fails on simple program victor dot pasko at gmail dot com
` (5 preceding siblings ...)
2010-07-13 17:08 ` jakub at gcc dot gnu dot org
@ 2010-07-14 10:11 ` victor dot pasko at gmail dot com
2010-07-16 3:55 ` victor dot pasko at gmail dot com
` (6 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: victor dot pasko at gmail dot com @ 2010-07-14 10:11 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug fortran/44927] static linkage with -lgomp fails on simple program
2010-07-13 8:41 [Bug fortran/44927] New: static linkage with -lgomp fails on simple program victor dot pasko at gmail dot com
` (6 preceding siblings ...)
2010-07-14 10:11 ` victor dot pasko at gmail dot com
@ 2010-07-16 3:55 ` victor dot pasko at gmail dot com
2010-07-16 4:29 ` kargl at gcc dot gnu dot org
` (5 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: victor dot pasko at gmail dot com @ 2010-07-16 3:55 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug fortran/44927] static linkage with -lgomp fails on simple program
2010-07-13 8:41 [Bug fortran/44927] New: static linkage with -lgomp fails on simple program victor dot pasko at gmail dot com
` (7 preceding siblings ...)
2010-07-16 3:55 ` victor dot pasko at gmail dot com
@ 2010-07-16 4:29 ` kargl at gcc dot gnu dot org
2010-07-16 7:10 ` burnus at gcc dot gnu dot org
` (4 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: kargl at gcc dot gnu dot org @ 2010-07-16 4:29 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug fortran/44927] static linkage with -lgomp fails on simple program
2010-07-13 8:41 [Bug fortran/44927] New: static linkage with -lgomp fails on simple program victor dot pasko at gmail dot com
` (8 preceding siblings ...)
2010-07-16 4:29 ` kargl at gcc dot gnu dot org
@ 2010-07-16 7:10 ` burnus at gcc dot gnu dot org
2010-07-16 14:48 ` kargl at gcc dot gnu dot org
` (3 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: burnus at gcc dot gnu dot org @ 2010-07-16 7:10 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug fortran/44927] static linkage with -lgomp fails on simple program
2010-07-13 8:41 [Bug fortran/44927] New: static linkage with -lgomp fails on simple program victor dot pasko at gmail dot com
` (9 preceding siblings ...)
2010-07-16 7:10 ` burnus at gcc dot gnu dot org
@ 2010-07-16 14:48 ` kargl at gcc dot gnu dot org
2010-07-19 10:25 ` victor dot pasko at gmail dot com
` (2 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: kargl at gcc dot gnu dot org @ 2010-07-16 14:48 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug fortran/44927] static linkage with -lgomp fails on simple program
2010-07-13 8:41 [Bug fortran/44927] New: static linkage with -lgomp fails on simple program victor dot pasko at gmail dot com
` (10 preceding siblings ...)
2010-07-16 14:48 ` kargl at gcc dot gnu dot org
@ 2010-07-19 10:25 ` victor dot pasko at gmail dot com
2010-07-19 16:53 ` jakub at gcc dot gnu dot org
2010-07-20 6:19 ` victor dot pasko at gmail dot com
13 siblings, 0 replies; 15+ messages in thread
From: victor dot pasko at gmail dot com @ 2010-07-19 10:25 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug fortran/44927] static linkage with -lgomp fails on simple program
2010-07-13 8:41 [Bug fortran/44927] New: static linkage with -lgomp fails on simple program victor dot pasko at gmail dot com
` (11 preceding siblings ...)
2010-07-19 10:25 ` victor dot pasko at gmail dot com
@ 2010-07-19 16:53 ` jakub at gcc dot gnu dot org
2010-07-20 6:19 ` victor dot pasko at gmail dot com
13 siblings, 0 replies; 15+ messages in thread
From: jakub at gcc dot gnu dot org @ 2010-07-19 16:53 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug fortran/44927] static linkage with -lgomp fails on simple program
2010-07-13 8:41 [Bug fortran/44927] New: static linkage with -lgomp fails on simple program victor dot pasko at gmail dot com
` (12 preceding siblings ...)
2010-07-19 16:53 ` jakub at gcc dot gnu dot org
@ 2010-07-20 6:19 ` victor dot pasko at gmail dot com
13 siblings, 0 replies; 15+ messages in thread
From: victor dot pasko at gmail dot com @ 2010-07-20 6:19 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2010-07-20 6:19 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-07-13 8:41 [Bug fortran/44927] New: static linkage with -lgomp fails on simple program victor dot pasko at gmail dot com
2010-07-13 9:22 ` [Bug fortran/44927] " jakub at gcc dot gnu dot org
2010-07-13 9:27 ` victor dot pasko at gmail dot com
2010-07-13 12:01 ` victor dot pasko at gmail dot com
2010-07-13 12:23 ` jakub at gcc dot gnu dot org
2010-07-13 12:37 ` victor dot pasko at gmail dot com
2010-07-13 17:08 ` jakub at gcc dot gnu dot org
2010-07-14 10:11 ` victor dot pasko at gmail dot com
2010-07-16 3:55 ` victor dot pasko at gmail dot com
2010-07-16 4:29 ` kargl at gcc dot gnu dot org
2010-07-16 7:10 ` burnus at gcc dot gnu dot org
2010-07-16 14:48 ` kargl at gcc dot gnu dot org
2010-07-19 10:25 ` victor dot pasko at gmail dot com
2010-07-19 16:53 ` jakub at gcc dot gnu dot org
2010-07-20 6:19 ` victor dot pasko at gmail dot com
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).