This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug fortran/63861] OpenACC coarray ICE (also with OpenMP?)
- From: "cesar at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Wed, 02 Dec 2015 17:08:16 +0000
- Subject: [Bug fortran/63861] OpenACC coarray ICE (also with OpenMP?)
- Auto-submitted: auto-generated
- References: <bug-63861-4 at http dot gcc dot gnu dot org/bugzilla/>
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
> <http://news.gmane.org/find-root.php?message_id=%3C877fkwn8p6.fsf%40kepler.
> 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.