[Bug fortran/95109] [11 regression] ICE in gfortran.dg/gomp/target1.f90 after r11-349
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95109 Tobias Burnus changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Tobias Burnus --- FIXED on mainline (GCC 11), backported to GCC 10 and to OG10 = devel/omp/gcc-10.
[Bug fortran/95109] [11 regression] ICE in gfortran.dg/gomp/target1.f90 after r11-349
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95109 --- Comment #8 from CVS Commits --- The releases/gcc-10 branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:f93eba8c5fde83100bf0854607848b6f50c8bbb2 commit r10-8721-gf93eba8c5fde83100bf0854607848b6f50c8bbb2 Author: Tobias Burnus Date: Wed Sep 9 11:54:43 2020 +0200 Fortran: Fixes for OpenMP loop-iter privatization (PRs 95109 + 94690) This commit also fixes a gfortran.dg/gomp/target1.f90 regression; target1.f90 tests the resolve.c and openmp.c changes. gcc/fortran/ChangeLog: PR fortran/95109 PR fortran/94690 * resolve.c (gfc_resolve_code): Also call gfc_resolve_omp_parallel_blocks for 'distribute parallel do (simd)'. * openmp.c (gfc_resolve_omp_parallel_blocks): Handle it. * trans-openmp.c (gfc_trans_omp_target): For TARGET_PARALLEL_DO_SIMD, call simd not do processing function. gcc/testsuite/ChangeLog: PR fortran/95109 PR fortran/94690 * gfortran.dg/gomp/openmp-simd-5.f90: New test. (cherry picked from commit 61c2d476a52bb108bd05d0226c5522bf0c4b24b5)
[Bug fortran/95109] [11 regression] ICE in gfortran.dg/gomp/target1.f90 after r11-349
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95109 --- Comment #7 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:61c2d476a52bb108bd05d0226c5522bf0c4b24b5 commit r11-3066-g61c2d476a52bb108bd05d0226c5522bf0c4b24b5 Author: Tobias Burnus Date: Wed Sep 9 09:33:51 2020 +0200 Fortran: Fixes for OpenMP loop-iter privatization (PRs 95109 + 94690) This commit also fixes a gfortran.dg/gomp/target1.f90 regression; target1.f90 tests the resolve.c and openmp.c changes. gcc/fortran/ChangeLog: PR fortran/95109 PR fortran/94690 * resolve.c (gfc_resolve_code): Also call gfc_resolve_omp_parallel_blocks for 'distribute parallel do (simd)'. * openmp.c (gfc_resolve_omp_parallel_blocks): Handle it. (gfc_resolve_do_iterator): Remove special code for SIMD, which is not needed. * trans-openmp.c (gfc_trans_omp_target): For TARGET_PARALLEL_DO_SIMD, call simd not do processing function. gcc/testsuite/ChangeLog: PR fortran/95109 PR fortran/94690 * gfortran.dg/gomp/combined-if.f90: Update scan-tree-dump-times for 'omp simd.*if'. * gfortran.dg/gomp/openmp-simd-5.f90: New test.
[Bug fortran/95109] [11 regression] ICE in gfortran.dg/gomp/target1.f90 after r11-349
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95109 --- Comment #6 from G. Steinmetz --- And reducing especially the directives : $ cat z1.f90 program p !$omp target data map(tofrom:n,r) !$omp target teams reduction(+:r) !$omp distribute parallel do simd collapse(2) do i = 1, 10 do j = 1, 10 end do end do !$omp end target teams !$omp end target data end
[Bug fortran/95109] [11 regression] ICE in gfortran.dg/gomp/target1.f90 after r11-349
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95109
--- Comment #5 from Dominique d'Humieres ---
Reduced testcase:
! { dg-do compile }
module target1
contains
subroutine foo (n, o, p, q, r, pp)
integer :: n, o, p, q, r, s, i, j
integer :: a (2:o)
integer, pointer :: pp
!$omp target data device (n + 1) if (n .ne. 6) map (tofrom: n, r)
!$omp target teams device (n + 1) if (n .ne. 6)map (from: n) &
!$omp & map (alloc: a(2:o)) num_teams (n + 4) thread_limit (n * 2) &
!$omp & default(shared) shared(n) private (p) reduction(+:r)
!$omp distribute parallel do simd if(n.ne.6)default(shared)&
!$omp & private (p) firstprivate (q) shared (n) reduction (+: r) &
!$omp & dist_schedule (static, 4) collapse (2) safelen(8) &
!$omp & num_threads (n + 4) proc_bind (spread) lastprivate (s) &
!$omp & schedule (static, 8)
do i = 1, 10
do j = 1, 10
r = r + 1
p = q
a(2+i*10+j) = p + q
s = i * 10 + j
end do
end do
!$omp end target teams
!$omp end target data
end subroutine
end module
[Bug fortran/95109] [11 regression] ICE in gfortran.dg/gomp/target1.f90 after r11-349
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95109 --- Comment #4 from Tobias Burnus --- (In reply to Martin Liška from comment #3) > Any update on the failing target1.f90 test-case? Not yet. What needs to be done is to mark loop variables as "private" – and attach this to the proper OpenMP directive; with "teams", "distribute" and multiple loops this can get rather complex. The middle end does this for "for" loops – but the Fortran FE *only* generates them for OpenMP loops – in particular for "simd". For normal Fortran loops, the ME does not recognize the loop variable. Hence, the complex algorithm of "2.19.1.1 Variables Referenced in a Construct" has to be implemented – i.e. skipping the private for those which already have firstprivate/lastprivate/private and attaching it to the correct directive. The ICE occurs if the private is attached to the wrong OpenMP directive which the ME then confuses. There can be a large number of directives combined (see target1.f90): !$omp target teams distribute parallel do … do i = 1, 10 do j = 1, 10 with some clauses like collapse(1) or collapse(2) or … The FE adds the "private" in gfc_resolve_do_iterator – and later in gfc_trans_omp_do (only for the OpenMP loops, there can be "normal" loops in between) and for combined directives above, they get split in gfc_split_omp_clauses – hence, the predetermined …private has end up on the right directive. I think adding 'private' only for non-OpenMP will avoid some split issues – but to do this, one has to evaluate 'collapse' etc. to know whether a loop becomes a ME-treated 'for' loop or not. And for nested omp directives, one has to attach the directive to the right directive. Example: !$omp teams !$omp distribute !$omp do do i = 1,n ! Omp loop, handled by ME do j = 1, m ! Fortran loop, unless collapse(2) … do i = 1,n … ! Fortran loop – not 'omp do' but inside 'omp distribute' To which directive should "private(i)" and private(j) be attached to? How differs this if there is a private/lastprivate/firstprivate on any of the directives? (The patch which causes this fail fixed other ICEs with another test case, but caused the target1.f90 fail. Thus, by undoing/doing those bits of r11-349 one can toggle between ICEs in the same ME function.)
[Bug fortran/95109] [11 regression] ICE in gfortran.dg/gomp/target1.f90 after r11-349
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95109 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #3 from Martin Liška --- Any update on the failing target1.f90 test-case?
[Bug fortran/95109] [11 regression] ICE in gfortran.dg/gomp/target1.f90 after r11-349
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95109 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Host|powerpc64*-linux-gnu|powerpc64*-linux-gnu ||x86_64-linux Last reconfirmed||2020-05-19 CC||msebor at gcc dot gnu.org --- Comment #2 from Martin Sebor --- Confirmed. Also reported on x86_64-linux here: https://gcc.gnu.org/pipermail/gcc-testresults/2020-May/561528.html
[Bug fortran/95109] [11 regression] ICE in gfortran.dg/gomp/target1.f90 after r11-349
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95109 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.0
[Bug fortran/95109] [11 regression] ICE in gfortran.dg/gomp/target1.f90 after r11-349
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95109 --- Comment #1 from Tobias Burnus --- Confirmed – see PR 94690 comment 10.
