Home > Archive > Fortran > April 2007 > gfortran, OpenMP, and AMD64 X2
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
gfortran, OpenMP, and AMD64 X2
|
|
|
| Hi,
I have an AMD64 X2 system (linux) and am trying to compile a program
that uses OpenMP. I've tried gfortran from both gcc 4.2 and the current
development trunk, but they both crash immediately with segmentation
faults (the program compiles with no warnings or errors). The program
is a simple hello world program. The crash occurs with the !$OMP
directives as the two functions are commented out. Any ideas? I
compiled with
gfortran -fopenmp hello.f90 -static
Thanks,
John
program hello
use omp_lib
implicit none
integer nthreads, tid, omp_get_num_threads, omp_get_thread_num
!$OMP PARALLEL PRIVATE(NTHREADS, TID)
! TID = OMP_GET_THREAD_NUM()
print *, 'hello world from thread = ', tid
if (tid .eq. 0) then
! nthreads = omp_get_num_threads()
print *, 'number of threads = ', nthreads
end if
!$OMP END PARALLEL
end program hello
| |
| Tobias Burnus 2007-04-17, 8:05 am |
| Hi,
your program has a small bug as
integer :: omp_get_num_threads, omp_get_thread_num
clash with the functions defined in omp_lib. As "gfortran -std=f95" or
"gfortran -pedantic" complains:
integer nthreads, tid, omp_get_num_threads, omp_get_thread_num
1
Error: Symbol 'omp_get_num_threads' at (1) already has basic type of
INTEGER
Otherwise, I get with gfortran 4.3.0 20070416 (x86_64-unknown-linux-
gnu) and with the Intel Fortran Compiler (ifort, 9.1) the same output:
hello world from thread = 0
number of threads = 2
hello world from thread = 1
and also valgrind does not complain.
If I compile the program with "TID=" and "nthreads =" commented out,
then there is a problem with
if(TID .eq. 0)
and
print *, 'number of threads = ', nthreads
Namely: The variables TID and nthreads are not initialized! However,
this should not cause a crash!
My program looks like:
---------------------
program hello
use omp_lib
implicit none
integer :: nthreads, tid
!$OMP PARALLEL PRIVATE(NTHREADS, TID)
TID = OMP_GET_THREAD_NUM()
print *, 'hello world from thread = ', tid
if (tid .eq. 0) then
nthreads = omp_get_num_threads()
print *, 'number of threads = ', nthreads
end if
!$OMP END PARALLEL
end program hello
---------------------
If this program still crashes, can you provide your exact gfortran
version (gfortran -v) and (in a personal email or in an email to
fortran -At- gcc . gnu . org) also the file dumped by compiling with
gfortran -fdump-tree-original -fopenmp mp.f90
(assuming you name the program "mp.f90"; the dump file is then
"mp.f90.003t.original")
Tobias
| |
|
| > The program is a simple hello world program. The crash occurs with the
> !$OMP directives as the two functions are commented out.
I can reproduce your crash with the following code:
integer :: tid
!$omp parallel private(tid)
tid = 0
if (tid .eq. 0) write(*,*) 'hello'
!$omp end parallel
end
$ gfortran -fopenmp hello.f90 -g -static && ./a.out
zsh: segmentation fault ./a.out
It's indeed a bug, I've filed it into our bug database: you can go at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31604 to check its progress
or add yourself to the CC list, to receive mail updates on its
resolution.
You can work around this bug by linking dynamically.
(PS: personnal thought: static linking is a royal pain wrt library
constructors and destructors.)
--
FX
| |
|
| FX wrote:
>
> I can reproduce your crash with the following code:
>
> integer :: tid
> !$omp parallel private(tid)
> tid = 0
> if (tid .eq. 0) write(*,*) 'hello'
> !$omp end parallel
> end
Actually, only a write statement is required to produce the segmentation
fault.
integer :: tid
!$omp parallel private(tid)
write(*,*) 'hello'
!$omp end parallel
>
> $ gfortran -fopenmp hello.f90 -g -static && ./a.out
> zsh: segmentation fault ./a.out
>
> It's indeed a bug, I've filed it into our bug database: you can go at
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31604 to check its progress
> or add yourself to the CC list, to receive mail updates on its
> resolution.
>
> You can work around this bug by linking dynamically.
>
> (PS: personnal thought: static linking is a royal pain wrt library
> constructors and destructors.)
Thanks, I'll try linking dynamically again. The main reason I was
linking statically was I was getting
gfortran.so: file not recognized: File format not recognized
errors. Any idea how to solve this without linking statically?
John
| |
|
| > gfortran.so: file not recognized: File format not recognized
What is the command-line that gives this error?
--
FX
| |
|
| FX wrote:
>
> What is the command-line that gives this error?
>
Sorry, I should have included the whole error message probably (I didn't
realized the line had wrapped)
~/gcc-trunk/bin/gfortran -fopenmp hello.f90
which produces
/home/john/gcc-trunk/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.0/../../../../lib64/libgfortran.so:
file not recognized: File format not recognized
collect2: ld returned 1 exit status
Also,
LD_LIBRARY_PATH=/home/john/gcc-trunk/lib64
John
| |
|
| > You can work around this bug by linking dynamically.
It's already known. I found this in a message by Jakub Jelinek, who
implemented OpenMP in GCC:
---------------------------
Static linking with -lpthread (which -fopenmp uses) is not supported in
glibc/NPTL. You can probably make it working by adding
-Wl,--whole-archive -lpthread -Wl,--no-whole-archive to the command line,
but there are no guarantees it will work.
Anyway, this is not a GCC bug but GLIBC feature.
---------------------------
It appears to be a general problem with GLIBC (although it's coined as a
feature).
--
FX
| |
|
| FX wrote:
>
> It's already known. I found this in a message by Jakub Jelinek, who
> implemented OpenMP in GCC:
>
> ---------------------------
> Static linking with -lpthread (which -fopenmp uses) is not supported in
> glibc/NPTL. You can probably make it working by adding
> -Wl,--whole-archive -lpthread -Wl,--no-whole-archive to the command line,
> but there are no guarantees it will work.
>
> Anyway, this is not a GCC bug but GLIBC feature.
> ---------------------------
>
> It appears to be a general problem with GLIBC (although it's coined as a
> feature).
>
Thanks,
I added those command line options and was able to link and run the
program correctly. I could never get the program to link dynamically
for some unknown reason. Hopefully I can figure out the problem or that
the dynamic-linking problem will solve itself when my distribution
updates to gcc 4.2.
John
| |
| Daniel Franke 2007-04-18, 8:04 am |
| John wrote:
> FX wrote:
> ~/gcc-trunk/bin/gfortran -fopenmp hello.f90
>
> /home/john/gcc-trunk/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.0/../../../../lib64/libgfortran.so:
> file not recognized: File format not recognized
> collect2: ld returned 1 exit status
>
> LD_LIBRARY_PATH=/home/john/gcc-trunk/lib64
Long shot: FCFLAGS+=-m64, maybe?
I'm running gfortran-4.2 and svn using OpenMP just fine on a similar
hardware.
My configuration:
$> gfortran-4.2 -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured
with: ../../svn/gcc-4.2-branch/configure --prefix=$(localpath) --with-gmp=$(localpath) --with-mpfr=$(localpath) --enable-bootstrap --enable-threads=posix --enable-shared --with-system-zlib --program-suffix=-4.2 --disable-nls --disable-multilib --enable-la
nguages=c,fortran
Thread model: posix
gcc version 4.2.0 20070417 (prerelease)
You may want to have a look at PR26165 [1] if you ever come
across "libgomp.spec not found".
Daniel
[1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26165
| |
|
| Daniel Franke wrote:
> John wrote:
>
>
> Long shot: FCFLAGS+=-m64, maybe?
>
> I'm running gfortran-4.2 and svn using OpenMP just fine on a similar
> hardware.
>
> My configuration:
> $> gfortran-4.2 -v
> Using built-in specs.
> Target: x86_64-unknown-linux-gnu
> Configured
> with: ../../svn/gcc-4.2-branch/configure --prefix=$(localpath)
--with-gmp=$(localpath) --with-mpfr=$(localpath) --enable-bootstrap
--enable-threads=posix --enable-shared --with-system-zlib
--program-suffix=-4.2 --disable-nls --disable-multilib
--enable-languages=c,fortran
> Thread model: posix
> gcc version 4.2.0 20070417 (prerelease)
>
> You may want to have a look at PR26165 [1] if you ever come
> across "libgomp.spec not found".
>
>
> Daniel
>
>
> [1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26165
>
Thanks, but it didn't seem to work. Haven't come across the
libgomp.spec problem yet. Here is the output when I use -v
Driving: /home/john/gcc-trunk/bin/gfortran -v -fopenmp omp_hello.f90
-lgfortranbegin -lgfortran -lm -shared-libgcc
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: /home/tob/projects/gcc/configure
--enable-languages=c,fortran --prefix=/projects/tob/gcc-trunk
Thread model: posix
gcc version 4.3.0 20070416 (experimental)
/home/john/gcc-trunk/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.3.0/f951
omp_hello.f90 -quiet -dumpbase omp_hello.f90 -mtune=generic -auxbase
omp_hello -version -fopenmp -fintrinsic-modules-path
/home/john/gcc-trunk/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.0/finclude
-o /tmp/ccF2Zegb.s
GNU F95 version 4.3.0 20070416 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.3.0 20070416 (experimental).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
as -V -Qy -o /tmp/cc8HBfGc.o /tmp/ccF2Zegb.s
GNU assembler version 2.16.1 (x86_64-pc-linux-gnu) using BFD version 2.16.1
Reading specs from
/home/john/gcc-trunk/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.0/
.../../../libgomp.spec
/home/john/gcc-trunk/bin/../libexec/gcc/x86_64-unknown-linux-gnu/
4.3.0/collect2 --eh-frame-hdr -m elf_x86_64 -dynamic-linker
/lib64/ld-linux-x86-64.so.2 /usr/lib/../lib64/crt1.o
/usr/lib/../lib64/crti.o
/home/john/gcc-trunk/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.0/
crtbegin.o
-L/home/john/gcc-trunk/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.0
-L/home/john/gcc-trunk/bin/../lib/gcc
-L/home/john/gcc-trunk/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.0/
.../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64
-L/home/john/gcc-trunk/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.0/
.../../.. /tmp/cc8HBfGc.o -lgfortranbegin -lgfortran -lm -lgomp -lgcc_s
-lgcc -lpthread -lc -lgcc_s -lgcc
/home/john/gcc-trunk/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.0/crtend.o
/usr/lib/../lib64/crtn.o
/home/john/gcc-trunk/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.0/
.../../../
.../lib64/libgfortran.so: file not recognized: File format not recognized
collect2: ld returned 1 exit status
John
| |
|
| > Target: x86_64-unknown-linux-gnu
> Configured with: /home/tob/projects/gcc/configure
> --enable-languages=c,fortran --prefix=/projects/tob/gcc-trunk
> Thread model: posix
> gcc version 4.3.0 20070416 (experimental)
I think those are binaries from Tobias Burnus. If you write to fortran at
gcc.gnu.org (the gfortran mailing-list), it's possible he'll have an idea
what's going on. You might want to include the output of the command:
ldd /home/john/gcc-trunk/lib64/libgfortran.so
in your mail.
--
FX
| |
|
|
|
|
|