[Bug fortran/63861] OpenACC coarray ICE (also with OpenMP?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63861 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |NEW --- Comment #8 from Dominique d'Humieres --- Compiling gfortran.dg/goacc/coarray.f95 with '-fcoarray=single -fopenacc' gives now an ICE /opt/gcc/_clean/gcc/testsuite/gfortran.dg/goacc/coarray.f95:23:0: !$acc parallel loop reduction(+:a) internal compiler error: in lower_oacc_reductions, at omp-low.c:5437 The change occurred between revisions r231086 (no ICE) and r231131 (ICE).
[Bug fortran/63861] OpenACC coarray ICE (also with OpenMP?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63861 cesar at gcc dot gnu.org changed: What|Removed |Added CC||cesar at gcc dot gnu.org --- Comment #10 from cesar at gcc dot gnu.org --- Thanks for reducing this Dominique. I'm not sure what caused the ICE yet, I don't think this test case is valid anymore. Basically, this test is trying to preform a reduction on a coarrray. Unlike openmp, openacc does not support array reductions. In fact, if you convert 'a' to a regular array, it would also cause an ICE. One of the solutions I was considering was to error if any array variables are used in as reduction variables. But I was thinking that would be too conservative. Consider 'reduction(+:var(1))'. Here var is an array, but the reduction is specifically operating on var element 1. The problem I came across here is that reductions on array elements in openmp are rejected as errors and I not sure why. I spent some time looking at it, but I kept on getting preempted by other tasks. This may be the case where the behavior of reductions in openmp diverges from openacc. With that in mind, I'm not sure why the ICE was exposed all of the sudden. My changes mostly updated the way that gang is parsed and how clauses in combined constructs are split. It looks like a sorry disappeared because the ICE occurs in omp-low.c.
[Bug fortran/63861] OpenACC coarray ICE (also with OpenMP?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63861
--- Comment #11 from Thomas Schwinge ---
(In reply to cesar from comment #10)
> Thanks for reducing this Dominique. I'm not sure what caused the ICE yet, I
> don't think this test case is valid anymore.
But still shouldn't result in an ICE.
> Basically, this test is trying to preform a reduction on a coarrray. Unlike
> openmp, openacc does not support array reductions. In fact, if you convert
> 'a' to a regular array, it would also cause an ICE.
Should possibly be rejected with an appropriate error diagnostic, but not cause
an ICE.
> One of the solutions I was considering was to error if any array variables
> are used in as reduction variables. But I was thinking that would be too
> conservative. Consider 'reduction(+:var(1))'. Here var is an array, but the
> reduction is specifically operating on var element 1.
Hmm, but is that useful enough to consider this special case?
> The problem I came across here is that reductions on array elements in
> openmp are rejected as errors and I not sure why. I spent some time looking
> at it, but I kept on getting preempted by other tasks. This may be the case
> where the behavior of reductions in openmp diverges from openacc.
>
> With that in mind, I'm not sure why the ICE was exposed all of the sudden.
> My changes mostly updated the way that gang is parsed and how clauses in
> combined constructs are split. It looks like a sorry disappeared because the
> ICE occurs in omp-low.c.
Quite right ("sorry disappeared"; see
.
[Bug fortran/63861] OpenACC coarray ICE (also with OpenMP?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63861 Dominique d'Humieres changed: What|Removed |Added CC||jules at gcc dot gnu.org --- Comment #9 from Dominique d'Humieres --- > The change occurred between revisions r231086 (no ICE) and r231131 (ICE). Reduced range from https://gcc.gnu.org/ml/gcc-regression/2015-12/ r231109 (no ICE), r231121 (ICE), likely r231112 or r231118.
[Bug fortran/63861] OpenACC coarray ICE (also with OpenMP?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63861
--- Comment #12 from cesar at gcc dot gnu.org ---
(In reply to Thomas Schwinge from comment #11)
> (In reply to cesar from comment #10)
> > Thanks for reducing this Dominique. I'm not sure what caused the ICE yet, I
> > don't think this test case is valid anymore.
>
> But still shouldn't result in an ICE.
I agree.
> > Basically, this test is trying to preform a reduction on a coarrray. Unlike
> > openmp, openacc does not support array reductions. In fact, if you convert
> > 'a' to a regular array, it would also cause an ICE.
>
> Should possibly be rejected with an appropriate error diagnostic, but not
> cause an ICE.
Yeah, I know. I was just raising this as a known issue that I'm working on.
> > One of the solutions I was considering was to error if any array variables
> > are used in as reduction variables. But I was thinking that would be too
> > conservative. Consider 'reduction(+:var(1))'. Here var is an array, but the
> > reduction is specifically operating on var element 1.
>
> Hmm, but is that useful enough to consider this special case?
Probably. Besides it also affects the c and c++ front ends.
> > The problem I came across here is that reductions on array elements in
> > openmp are rejected as errors and I not sure why. I spent some time looking
> > at it, but I kept on getting preempted by other tasks. This may be the case
> > where the behavior of reductions in openmp diverges from openacc.
> >
> > With that in mind, I'm not sure why the ICE was exposed all of the sudden.
> > My changes mostly updated the way that gang is parsed and how clauses in
> > combined constructs are split. It looks like a sorry disappeared because the
> > ICE occurs in omp-low.c.
>
> Quite right ("sorry disappeared"; see
> schwinge.homeip.net%3E>.
Ok. I'm testing a patch which teaches the fortran front end to error on any
type of array reductions. It's a little bit conservative because it doesn't
permit reductions on array elements yet. But at least it doesn't ICE. If you
want, I can take a look at those gimplifier changes once I'm done with this.
Otherwise, I still need to work on the c++ routine error messages.
[Bug fortran/63861] OpenACC coarray ICE (also with OpenMP?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63861 cesar at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #14 from cesar at gcc dot gnu.org --- Fixed in r231204. Array reductions aren't supported in OpenACC 2.0. So now the fortran front end generates error when it encounters such a reduction.
[Bug fortran/63861] OpenACC coarray ICE (also with OpenMP?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63861 --- Comment #13 from cesar at gcc dot gnu.org --- Author: cesar Date: Wed Dec 2 19:59:27 2015 New Revision: 231204 URL: https://gcc.gnu.org/viewcvs?rev=231204=gcc=rev Log: gcc/fortran/ PR fortran/63861 * openmp.c (gfc_match_omp_clauses): Allow subarrays for acc reductions. (resolve_omp_clauses): Error on any acc reductions on arrays. gcc/testsuite/ * gfortran.dg/goacc/array-reduction.f90: New test. * gfortran.dg/goacc/assumed.f95: Update expected diagnostics. * gfortran.dg/goacc/coarray.f95: Likewise. * gfortran.dg/goacc/coarray_2.f90: Likewise. * gfortran.dg/goacc/reduction-2.f95: Likewise. * gfortran.dg/goacc/reduction.f95: Likewise. Added: trunk/gcc/testsuite/gfortran.dg/goacc/array-reduction.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/openmp.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/goacc/assumed.f95 trunk/gcc/testsuite/gfortran.dg/goacc/coarray.f95 trunk/gcc/testsuite/gfortran.dg/goacc/coarray_2.f90 trunk/gcc/testsuite/gfortran.dg/goacc/reduction-2.f95 trunk/gcc/testsuite/gfortran.dg/goacc/reduction.f95
[Bug fortran/63861] OpenACC coarray ICE (also with OpenMP?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63861 --- Comment #7 from Dominique d'Humieres --- The ICE is gone and between revisions r229303 and r229482 compiling the test gcc/testsuite/gfortran.dg/goacc/coarray.f95 with '-fcoarray=single -fopenacc' gives /opt/gcc/_clean/gcc/testsuite/gfortran.dg/goacc/coarray.f95:13:0: !$acc declare device_resident (a) ^ sorry, unimplemented: directive not yet implemented /opt/gcc/_clean/gcc/testsuite/gfortran.dg/goacc/coarray.f95:21:0: !$acc host_data use_device (a) ^ sorry, unimplemented: directive not yet implemented Is what remains duplicate of pr63859?
[Bug fortran/63861] OpenACC coarray ICE (also with OpenMP?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63861 Dominique d'Humieres changed: What|Removed |Added Status|NEW |WAITING
[Bug fortran/63861] OpenACC coarray ICE (also with OpenMP?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63861 Thomas Schwinge changed: What|Removed |Added Status|WAITING |NEW CC||tschwinge at gcc dot gnu.org --- Comment #6 from Thomas Schwinge --- (In reply to Dominique d'Humieres from comment #5) > Is this fixed after r220189? No.
[Bug fortran/63861] OpenACC coarray ICE (also with OpenMP?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63861 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-10-20 Ever confirmed|0 |1 --- Comment #5 from Dominique d'Humieres --- Is this fixed after r220189?
[Bug fortran/63861] OpenACC coarray ICE (also with OpenMP?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63861 --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org --- Author: burnus Date: Tue Jan 27 19:57:55 2015 New Revision: 220189 URL: https://gcc.gnu.org/viewcvs?rev=220189root=gccview=rev Log: 2015-01-27 Tobias Burnus bur...@net-b.de PR fortran/63861 gcc/fortran/ * trans-openmp.c (gfc_has_alloc_comps, gfc_trans_omp_clauses): Fix handling for scalar coarrays. * trans-types.c (gfc_get_element_type): Add comment. gcc/testsuite/ * gfortran.dg/goacc/coarray_2.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/goacc/coarray_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-openmp.c trunk/gcc/fortran/trans-types.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/63861] OpenACC coarray ICE (also with OpenMP?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63861 --- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org --- Comment 3 fixed two issues with gcc/testsuite/gfortran.dg/goacc/coarray.f95. Still to do: * gcc/testsuite/gfortran.dg/goacc/coarray_2.f90 contains a FIXME for a reduction(+:a) variable. For an allocatable scalar coarray, that will lead to an ICE in an assignment a = 0. The problem seems to relate to calling alloc_scalar_allocatable_for_assignment from gfc_trans_assignment_1, which shall not be called at all. (The semantics say that for coarrays those shall always be allocated, when used and noreallocation shall be done. Coarray (de)allocations are always colletively done across all images (= processes)). I wonder whether there are similar other issues; the same no-realloc also applies to allocatable array coarrays. * One probably should check for coindexed variables (e.g. a[i] or b(1:8)[5], where the [...] refers to a remote image). For everything handled as pointer or within an offloaded region, that won't work and should be invalid. At places where a temporary is fine, it can be used (cf. dumps with -fcoarray=lib). I have no idea whether there is an issue in either the OpenMP/OpenACC directives or whether it would be testable for target/acc kernels/parallel regions. Probably only for those declaring a procedure (routine) to be offloadable.
[Bug fortran/63861] OpenACC coarray ICE (also with OpenMP?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63861 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||openmp Summary|OpenACC coarray ICE |OpenACC coarray ICE (also ||with OpenMP?) --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org --- With the patch for PR64726 applied and the ACC CACHE commented, the program gets stuck (endless loop) for the code in gcc/testsuite/gfortran.dg/goacc/coarray.f95. It works, if one changes the scalar coarray into either an array coarray or into a noncoarray scalar. I think gfc_has_alloc_comps just needs to be updated to handle coarrays, which use an array descriptor but aren't true arrays. (I think GFC_TYPE_ARRAY_RANK(...) == 0 can be used to detect this, but that might not work for all array types.) I marked it as OpenMP as it is probably also possible to trigger this for some OpenMP code. Even though, I do not have a test case. Backtrace: #1 gfc_get_element_type (type=0x720f25e8) at ../../gcc/fortran/trans-types.c:1180 #2 0x00742f85 in gfc_has_alloc_comps (type=optimized out, decl=optimized out) at ../../gcc/fortran/trans-openmp.c:193 #3 0x0099eb12 in gimplify_scan_omp_clauses (list_p=0x720f32a0, pre_p=pre_p@entry=0x7fffd918, region_type=region_type@entry=ORT_TARGET) at ../../gcc/gimplify.c:6062 #4 0x009a07c8 in gimplify_omp_workshare (expr_p=expr_p@entry=0x720eb778, pre_p=pre_p@entry=0x7fffd918) at ../../gcc/gimplify.c:7307
