[Bug c++/102854] New: [OpenMP] Bogus "initializer expression refers to iteration variable" when using templates

[Bug c++/102854] New: [OpenMP] Bogus "initializer expression refers to iteration variable" when using templates

[burnus at gcc dot gnu.org]

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

            Bug ID: 102854
           Summary: [OpenMP] Bogus "initializer expression refers to
                    iteration variable" when using templates
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Keywords: openmp, rejects-valid
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: burnus at gcc dot gnu.org
                CC: jakub at gcc dot gnu.org
  Target Milestone: ---

The following code compiles with the "typedef" but fails when used as
"template" with:

fooc.c:9:3: error: initializer expression refers to iteration variable ‘i’
    9 |   for (IndexType i = 0; i < N; ++i)
      |   ^~~

Long version:
https://github.com/SOLLVE/sollve_vv/blob/master/tests/5.0/application_kernels/lsms_triangular_packing.cpp

[Side note: According to the notes in the Pull Request #225, it works with LLVM
13 but fails with LLVM 11 and 12.]

Reduceted testcase:

// typedef IndexType int;  // < works:
template <typename IndexType>  // < fails
void
foo (IndexType N, IndexType M)
{
  #pragma omp target teams distribute parallel for collapse(2)
  for (IndexType i = 0; i < N; ++i)
    for (IndexType k = i; k < M; ++k)
      ;
}

[Bug c++/102854] [OpenMP] Bogus "initializer expression refers to iteration variable" when using templates

[burnus at gcc dot gnu.org]

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

--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> ---
For the non-template case (with int / IndexType reversed, (ups!)):

finish_omp_for's vec<tree> *orig_inits is an empty vector

but for the template, it isn't (it contains '0' and 'i'); thus, the following
check is run and fails:

      FOR_EACH_VEC_ELT (*orig_inits, i, orig_init)
        if (orig_init
            && !c_omp_check_loop_iv_exprs (locus,

The reason is that  type_dependent_expression_p (decl) == true in
cp_parser_omp_for_loop_init.

[Bug c++/102854] [OpenMP] Bogus "initializer expression refers to iteration variable" when using templates

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 51647
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51647&action=edit
gcc12-pr102854-wip.patch

WIP patch.  Clearly still more work is needed, apparently pointer iterators
in non-rectangular loops are rejected, like:
void
foo ()
{
  int a[1024];
  int *p, *q;
  #pragma omp parallel for collapse(2)
  for (p = &a[0]; p < &a[512]; p++)
    for (q = p + 64; q < p + 128; q++)
      ;
}
and enabling it result in ICEs during omp-expand.c.  Furthermore, for both
pointer and random access iterator non-rect loops, I should verify we only
allow the var-outer, var-outer + a2, a2 + var-outer and var-outer - a2 forms
and no others and test code generation.

[Bug c++/102854] [OpenMP] Bogus "initializer expression refers to iteration variable" when using templates

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:6b0f35299bd1468ebc13b900a73b7cac6181a2aa

commit r12-4732-g6b0f35299bd1468ebc13b900a73b7cac6181a2aa
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Wed Oct 27 09:16:48 2021 +0200

    openmp: Don't reject some valid initializers or conditions of
non-rectangular loops [PR102854]

    In C++, if an iterator has or might have (e.g. dependent type) class type
we
    remember the original init expressions and check those separately for
presence
    of iterators, because for class iterators we turn those into expressions
that
    always do contain reference to the current iterator.  But this resulted in
    rejecting valid non-rectangular loop where the dependent type is later
instantiated
    to an integral type.

    Non-rectangular loops with class random access iterators remain broken,
that is something
    to be fixed incrementally.

    2021-10-27  Jakub Jelinek  <jakub@redhat.com>

            PR c++/102854
    gcc/c-family/
            * c-common.h (c_omp_check_loop_iv_exprs): Add enum tree_code
argument.
            * c-omp.c (c_omp_check_loop_iv_r): For trees other than decls,
            TREE_VEC, PLUS_EXPR, MINUS_EXPR, MULT_EXPR, POINTER_PLUS_EXPR or
            conversions temporarily clear the 3rd bit from d->kind while
walking
            subtrees.
            (c_omp_check_loop_iv_exprs): Add CODE argument.  Or in 4 into
data.kind
            if possibly non-rectangular.
    gcc/cp/
            * semantics.c (handle_omp_for_class_iterator,
            finish_omp_for): Adjust c_omp_check_loop_iv_exprs caller.
    gcc/testsuite/
            * g++.dg/gomp/loop-3.C: Don't expect some errors.
            * g++.dg/gomp/loop-7.C: New test.

[Bug c++/102854] [OpenMP] Bogus "initializer expression refers to iteration variable" when using templates

[burnus at gcc dot gnu.org]

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

--- Comment #4 from Tobias Burnus <burnus at gcc dot gnu.org> ---
The testcase of comment 2 seems to be the same as the one of
bug 106449 comment 4, which went in as

r13-1887-g97d32048c04e97  openmp: Fix up handling of non-rectangular simd loops
with pointer type iterators [PR106449]

A slightly modified variant of that testcase went in follow-up commit

r13-1893-g85fe7e7dd1f146  Add libgomp.c-c++-common/pr106449-2.c

* * *

From the bug comments, it seems as if the following remains:

"Non-rectangular loops with class random access iterators remain broken, that
is something to be fixed incrementally."

* * *

However, given the commit for PR106449 (see above) and the earlier commit
r12-4733-g2084b5f42a4432  openmp: Allow non-rectangular loops with pointer
iterators
(committed right after the commit of comment 3):

I wonder whether the only thing that remains to be done is to add a real C++
testcase for random access iterator non-rect loops - assuming that the pointer
patches cover all what's needed in terms of compiler support.

[Bug c++/102854] [OpenMP] Bogus "initializer expression refers to iteration variable" when using templates

[burnus at gcc dot gnu.org]

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #5 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Close as FIXED - based on

* my previous comment (comment 4)
* based on the following:

(In reply to Jakub Jelinek from comment #2)
> WIP patch.  Clearly still more work is needed, apparently pointer iterators
> in non-rectangular loops are rejected, like:
(example that is committed as part of PR106449)

> and enabling it result in ICEs during omp-expand.c.  Furthermore, for both
> pointer and random access iterator non-rect loops,
I think we cannot really use non-rectangular loops with random-access
iterators. 

It works fine as long as the outer and the inner loop access different
variables, an example for this is libgomp.c++/collapse-2.C → 
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libgomp/testsuite/libgomp.c++/collapse-2.C;hb=HEAD

But I currently see no way to use in the outer loop
* a C++ iterator
* a range-based for loop
* a C-style index-variable loop
and then to use 'outer' in any way, except of having yet another classic
C-style loop.
Everything else I came up ends up using an expression involving the outer
iteration variable and not the bare variable. But that's rejected ("expression
refers to iteration variable" error).

> I should verify we only
> allow the var-outer, var-outer + a2, a2 + var-outer and var-outer - a2 forms
> and no others and test code generation.

I believe that's what r12-4733-g2084b5f42a4432da8b0625f9c669bf690ec46468 does
in c-c++-common/gomp/loop-9.c →
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/testsuite/c-c++-common/gomp/loop-9.c;hb=HEAD

(Admittedly only for "initializer expression" and not for "condition
expression" or "increment expression", but I can confirm that at last the
condition error works.)