From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 65C043858C66; Wed, 11 Jan 2023 15:59:58 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 65C043858C66
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1673452798;
	bh=OUjQPOKNox1aVAv7GtjooRBbXAbPYQGOx5ow9sUO9L4=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=p5Zx99qt/Z8HeaGz5vm+V74b5N7/YHjvz0whHXVLzDgZu8MsATGvJ735qbWDCVMKS
	 0MXQh9WTQbvcQuISpxLQ4dHB9kw2xHOjqpsLi27Jw0NENuvz/oq2Of8spK6sRW74Q/
	 +mKL14NTFd5HIFFLqsl5UQ0U5scBv0TE+BfwyPDE=
From: "burnus at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/107424] [13 Regression] ICE in gfc_trans_omp_do, at
 fortran/trans-openmp.cc:5397 - and wrong code - with non-rectangular loops
Date: Wed, 11 Jan 2023 15:59:57 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 13.0
X-Bugzilla-Keywords: ice-on-valid-code, openmp, wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: burnus at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P4
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 13.0
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-107424-4-VqrWciynAe@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-107424-4@http.gcc.gnu.org/bugzilla/>
References: <bug-107424-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

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

--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Commenting out the 'gcc_assert' of comment 0, it compiles and produces the
following dump.
I don't understand why there is a 'lastprivate' =E2=80=93 and 'i' in the bo=
unds are
wrong: for the first iteration, it is undefined and otherwise, it lags alwa=
ys
behind.

          #pragma omp simd lastprivate(count.0) collapse(2)
          for (count.0 =3D 0; count.0 < 5; count.0 =3D count.0 + 1)
            for (j =3D 1; j <=3D i; j =3D j + 1)
              {
                i =3D count.0 * 2 + 1;
                L.1:;
              }

And yet another variant:
   !$omp do simd collapse(2)
   do i =3D 1, 9, 2
      do j =3D 1, i, 2
i.e. both with non-unit strides. Then the result is still an ICE; commenting
the assert, the result is:

    D.4265 =3D (i + 1) / 2;  // Ups! This should use 'count.1' and shall no=
t be
hoisted!
    #pragma omp for collapse(2)
      {
        {
          #pragma omp simd lastprivate(count.1) lastprivate(count.0)
collapse(2)
          for (count.0 =3D 0; count.0 < 5; count.0 =3D count.0 + 1)
            for (count.1 =3D 0; count.1 < D.4265; count.1 =3D count.1 + 1)
              {
                i =3D count.0 * 2 + 1;
                j =3D count.1 * 2 + 1;
                L.1:;
              }

Here, COUNT is used in the inner loop - that would be also the option for t=
he
stride=3D=3D1 case, but as the expression needs to be in the condition alre=
ady, it
might be better to have for inner stride =3D=3D 1:
            for (j =3D 1; j <=3D count.0 * 2 + 1; j =3D j + 1)
and for inner stride =3D=3D 2:
            for (j =3D 1; j <=3D (count.0 * 2 + 1 + 1) / 2; j =3D j + 1)

We probably need to check whether any of lb,ub,stride contains a parent loop
var.=