https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63861
--- Comment #11 from Thomas Schwinge <tschwinge at gcc dot gnu.org> ---
(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
<http://news.gmane.org/find-root.php?message_id=%3C877fkwn8p6.fsf%40kepler.schwinge.homeip.net%3E>.
