--- 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 ad
--- 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).
--- 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.or
--- 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
--- 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 thr
--- 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
--- 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
--- 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
--- 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
--- 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 _gfor
--- 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:
--- 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
--- 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
/u
--- 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
14 matches
Mail list logo
