For this test case: program F03_2_9_3_6_2c ! derived from OpenMP test omp3f/F03_2_9_3_6_2c.f90 ! REFERENCES ! OpenMP 3.0, p. 100, lines 10-12 ! OpenMP 3.0, p. 316, lines 18-22 use omp_lib implicit none integer, parameter :: NT = 4 integer :: thread_num1, thread_num2, thread_num3 integer, allocatable :: thread_num_sums(:) integer :: i call omp_set_dynamic(.false.) call omp_set_num_threads(NT) allocate(thread_num_sums(NT)) thread_num_sums = 0 !$omp parallel !$omp sections reduction(+:thread_num_sums) !$omp section thread_num_sums = omp_get_thread_num() thread_num1 = omp_get_thread_num() !$omp section thread_num_sums = omp_get_thread_num() thread_num2 = omp_get_thread_num() !$omp section thread_num_sums = omp_get_thread_num() thread_num3 = omp_get_thread_num() !$omp end sections !$omp end parallel do i = 1, NT if (thread_num_sums(i) /= thread_num1+thread_num2+thread_num3) then write (*,fmt="('FAIL - thread_num_sums(',i2, ') == ',i10, & ' (expected',i2,')')") & i, thread_num_sums(i), thread_num1+thread_num2+thread_num3 else write (*,fmt="('thread',i2,' thread_num_sums(i) = ',i2)") & i, thread_num_sums(i) end if end do end program F03_2_9_3_6_2c the compiler aborts: > gfortran -fopenmp test.f90 test.f90: In function 'f03_2_9_3_6_2c': test.f90:20: internal compiler error: in single_pred_edge, at basic-block.h:658 Please submit a full bug report, with preprocessed source if appropriate. Additional comment from the OpenMP testers: The GNU gfortran compiler gets an internal error when compiling this test case when the REDUCTION appears on a SECTIONS. The OpenMP API version 3 (May 2008) p. 316 lines 18-20 states: "In Version 3.0, Fortran allocatable arrays may appear in ... reduction ... clauses." The API also states on p. 100 line 10-23: "An original list item with the ALLOCATABLE attribute must be in the allocated state at entry to the construct containing the reduction clause. Additionally, the list item must not be deallocated and/or allocated within the region."
Created attachment 19708 [details] gcc45-pr42866.patch Patch I'm testing. BTW, the provided testcase is wrong, if more than one section is scheduled on the same thread, it will abort. The problem is that it overwrites the reduction array in each section rather than adds to it, so it can only succeed if each section is scheduled in a different thread. But scheduling of !$omp sections is implementation defined, there are no restrictions on that choice.
Subject: Bug 42866 Author: jakub Date: Tue Jan 26 09:47:45 2010 New Revision: 156235 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156235 Log: PR fortran/42866 * omp-low.c (expand_omp_sections): Only use single_pred if l2_bb is single_pred_p. * testsuite/libgomp.fortran/allocatable5.f90: New test. Added: trunk/libgomp/testsuite/libgomp.fortran/allocatable5.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/omp-low.c trunk/libgomp/ChangeLog
Subject: Bug 42866 Author: jakub Date: Tue Jan 26 09:51:23 2010 New Revision: 156236 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156236 Log: PR fortran/42866 * omp-low.c (expand_omp_sections): Only use single_pred if l2_bb is single_pred_p. * testsuite/libgomp.fortran/allocatable5.f90: New test. Added: branches/gcc-4_4-branch/libgomp/testsuite/libgomp.fortran/allocatable5.f90 Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/omp-low.c branches/gcc-4_4-branch/libgomp/ChangeLog
Fixed.
*** Bug 43338 has been marked as a duplicate of this bug. ***
*** Bug 43712 has been marked as a duplicate of this bug. ***