[Bug fortran/107424] [13 Regression] ICE in gfc_trans_omp_do, at fortran/trans-openmp.cc:5397 - and wrong code - with non-rectangular loops

["jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107424

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I think there are multiple issues.  For the do i = 1, 9, 1 case, the bug is
that we:
      gfc_init_se (&se, NULL);
      gfc_conv_expr_val (&se, code->ext.iterator->end);
      gfc_add_block_to_block (pblock, &se.pre);
      to = gfc_evaluate_now (se.expr, pblock);
and therefore evaluate the upper expression (but ditto the lower expression)
before the loop nest into a temporary rather than keeping it directly in the
expression.
That is fine for the cases where the expressions are loop invariant, which was
always the case before non-rectangular loops were introduced, but is not ok for
non-rectangular loops.  I think the above patch deals with that somehow, but
haven't studied yet exactly how.  Don't know about the step2 case on the outer
loop, but guess it is similar to the below thing too.
Another problem is that for steps other than -1 and 1, we use the non-simple
expansion:
          /* STEP is not 1 or -1.  Use:
             for (count = 0; count < (to + step - from) / step; count++)
               {
                 dovar = from + count * step;
                 body;
               cycle_label:;
               }  */
If the inner loop of non-rectangular loop nest (well, in particular whenever
from or to
uses some outer loop iterator and is one of the allowed non-rectangular forms):
var-outer
var-outer + a2
a2 + var-outer
var-outer - a2
a2 - var-outer
a1 * var-outer
a1 * var-outer + a2
a2 + a1 * var-outer
a1 * var-outer - a2
a2 - a1 * var-outer
var-outer * a1
var-outer * a1 + a2
a2 + var-outer * a1
var-outer * a1 - a2
a2 - var-outer * a1
then using the non-simple expansion just can't work, the middle-end expects
the init and cond expressions to be literally something from the above list,
if that is turned into something divided by step, we've lost.
Now, the reason I've added the above expansion is because the middle-end
representation was chosen to be of the C/C++ loops and I wasn't sure if the
Fortran DO loop semantics
can be easily mapped to it.  For the non-rectangular loops, I'm afraid we have
to,
or have some flag on each of the OMP_FOR/GOMP_FOR loops to request Fortran
semantics.
If we do the latter, we'd need to adjust the middle-end (omp_extract_for_data,
everything that computes number of iterations, omp-expand loop expansion) to
handle that.
And I believe the non-simple outer loop is the same thing, for the
non-rectangular loops
the middle-end relies on the inner loop expressions that refer to var-outer to
be actually the outer loop's iterator.
So if we use the non-simple expansion for the outer loop:
             for (count = 0; count < (to + step - from) / step; count++)
               {
                 dovar = from + count * step;
                 body;
that would mean remapping the var_outer (aka dovar) in those expressions to
count based computations.