From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 6A35B3857438; Fri, 13 Jan 2023 10:46:05 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6A35B3857438 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1673606765; bh=ulUquzftMg0vmra5mOFgs0gx9kNblr8FuILiRmspKBM=; h=From:To:Subject:Date:In-Reply-To:References:From; b=KGlwontta/iAOJecrzRUwHVl6xTjjrSI6c9SpsuXZxZrAFmoEFv5AkReyILY4/PAL IcHMR7UUuM2X7CINuiSkIHQtfAHYLk4xFjNmlXm9XxP33VqorNjgcbLWGKEJE6NFa1 VlWxcWq4rTZezjfm+epRL5u5XaZbLemZwOPf/wbg= From: "burnus at gcc dot 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: Fri, 13 Jan 2023 10:46:03 +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: attachments.created Message-ID: In-Reply-To: References: 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: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D107424 --- Comment #4 from Tobias Burnus --- Created attachment 54265 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=3D54265&action=3Dedit WIP patch (with one WIP testcase) This patch should address the issues of this PR reported so far. But there two issues: (A) I am not sure whether the implicit 'lastprivate' should be added for SIMD or not. (B) there is an odd issue with lastprivate after gimplify, before it looks fine. (A) 'lastprivate' or not (refers to the patch itself): The SIMD/!simple change is because of: If there is no unit stride, 'count' is created (+ 'lastprivate(count)'). For collapse =3D=3D 1, 'linear' is added and later due to the 'dovar_foun= d =3D 3', OMP_CLAUSE_LINEAR_STMT (c) =3D ... For collapse > 1, nothing was added =E2=80=93 such that the code trying t= o add a ..._STMT failed to find a clause + and the 'c !=3D NULL' assert then fa= iled. The current patch adds 'lastprivate' in this case =E2=80=93 an alternativ= e would be to move the 'dovar_found =3D 3' into the 'if'. (The lastprivate(count) would still be added.) It is not quite clear to me what OpenMP requires - lastprivate or nothing (TODO: check). (B) The following code goes wrong; I converted it as closely as possible to= C and the C program works fine. integer :: n,m,p, i,j,k n =3D 11; m =3D 23; p =3D 27 !$omp simd collapse(3) lastprivate(k) do i =3D 1, n do j =3D 1, m do k =3D j - 41, p if (k < 1 - 41 .or. k > p) error stop end do end do end do end First, without the patch, the 'j - 41' is evaluated before the loop, which = is obviously wrong: D.4268 =3D j + -41; #pragma omp simd lastprivate(k) collapse(3) ... for (k =3D D.4268; k <=3D p; k =3D k + 1) But with the patch, it seems to be fine: #pragma omp simd lastprivate(j) lastprivate(i) lastprivate(k) collapse(3) for (i =3D 1; i <=3D n; i =3D i + 1) for (j =3D 1; j <=3D m; j =3D j + 1) for (k =3D j + -41; k <=3D p; k =3D k + 1) if (k < -40 || k > p) However, the gimple dump has the following - note the 'k =3D D.4287' where = the RHS is uninitialized! n =3D 11; m =3D 23; p =3D 27; #pragma omp simd lastprivate(j) lastprivate(i) lastprivate(k) collaps= e(3) private(k.9) private(j.6) private(i.3) private(dt_parm.0) for (i.3 =3D 1; i.3 <=3D n; i.3 =3D i.3 + 1) for (j.6 =3D 1; j.6 <=3D m; j.6 =3D j.6 + 1) for (k.9 =3D D.4287; k.9 <=3D p; k.9 =3D k.9 + 1) BTW: The attached patch contains a testcase from which (B) has been extract= ed as reduced fail. TODO: Besides fixing issue (B) and checking (A), some more testcases are ne= eded + fixing issues popping up when doing so. (PS: Currently, the start/end/step expressions are put into the loop even if they do not depend on another loop variable - this could be optimized, but = my feeling is that this is not worthwhile.)=