For this version: > gfortran -v Using built-in specs. COLLECT_GCC=/opt/gcc/4.5.0/bin/../snos/bin/gfortran COLLECT_LTO_WRAPPER=/opt/gcc/4.5.0/snos/libexec/gcc/x86_64-suse-linux/4.5.0/lto-wrapper Target: x86_64-suse-linux Configured with: ../xt-gcc-4.5.0/configure --prefix=/opt/gcc/4.5.0/snos --disable-nls --libdir=/opt/gcc/4.5.0/snos/lib --enable-languages=c,c++,fortran --with-gxx-include-dir=/opt/gcc/4.5.0/snos/include/g++ --with-slibdir=/opt/gcc/4.5.0/snos/lib --with-system-zlib --enable-shared --enable-__cxa_atexit x86_64-suse-linux --with-mpc=/opt/gcc/mpc/0.8.1 --with-mpfr=/opt/gcc/mpfr/2.4.2 --with-gmp=/opt/gcc/gmp/4.3.2 --with-sysroot= Thread model: posix gcc version 4.5.0 20100414 (Cray Inc.) (GCC) And this compile script: > cat compile.gnu ftn -fopenmp -c mod_init_openmp.f90 ftn -fopenmp -c mod_globals.f90 ftn -fopenmp -c mod_mysubs.f90 ftn -fopenmp -c mod_display_arrays.f90 ftn -fopenmp mod_init_openmp.o mod_globals.o mod_mysubs.o mod_display_arrays.o test_loop1.f90 > ./a.out.gnu Running on 2 threads Iteration = 0 After sub1: Array = pb 2.000 2.000 2.000 2.000 2.000 2.000 2.000 2.000 2.000 2.000 2.000 2.000 2.000 2.000 2.000 2.000 2.000 2.000 2.000 2.000 ...... After sub2: Array = out2 68.000 68.000 68.000 68.000 68.000 68.000 68.000 68.000 68.000 68.000 68.000 68.000 68.000 68.000 68.000 68.000 68.000 68.000 68.000 68.000 Iteration = 6 Segmentation fault
Comments from original submitter: A [deleted] user has given me the following code which fails with gcc/4.5.0. The code is OK with PGI and CCE. The problem seems to come about from the use of threadprivate in mod_globals.f90 and using the loop with the copyin clause in test_loop1.f90. If the threadprivate is commented out, and the copyin replaced with a private clause, all is well.
Created attachment 21579 [details] Test case, including source files and compile script Attached tar.gz file contains the source files and the compile.gnu script. Compilation completes, but execution of the a.out results in segfault.
This is invalid. See OpenMP 3.0, 2.9.4.1, COPYIN restrictions on page 102, lines 17-18: An array with the ALLOCATABLE attribute must be in the allocated state. Each thread's copy of that array must be allocated with the same bounds. In the testcase pb isn't in allocated state. See also http://openmp.org/forum/viewtopic.php?f=5&t=7&start=10#p292 for more details. I hope this is going to be changed for OpenMP 3.1, when its draft is released, we'll implement it the way it is written there.