From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id A4A303838008; Tue, 10 May 2022 08:23:01 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A4A303838008 From: "cvs-commit at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/102860] [12 regression] libgomp.fortran/simd2.f90 ICEs after r12-4526 Date: Tue, 10 May 2022 08:23:01 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end X-Bugzilla-Version: 12.0 X-Bugzilla-Keywords: ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: cvs-commit at gcc dot gnu.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: jakub at gcc dot gnu.org X-Bugzilla-Target-Milestone: 12.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: 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 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2022 08:23:01 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D102860 --- Comment #15 from CVS Commits --- The releases/gcc-10 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:03bd2b252bca8c0ba4aeecab8b560d751f2ef57d commit r10-10669-g03bd2b252bca8c0ba4aeecab8b560d751f2ef57d Author: Jakub Jelinek Date: Wed Jan 19 15:03:45 2022 +0100 match.pd, optabs: Avoid vectorization of {FLOOR,CEIL,ROUND}_{DIV,MOD}_E= XPR [PR102860] power10 has modv4si3 expander and so vectorizes the following testcase where Fortran modulo is FLOOR_MOD_EXPR. optabs_for_tree_code indicates that the optab for all the *_MOD_EXPR variants is umod_optab or smod_optab, but that isn't true, that optab actually expands just TRUNC_MOD_EXPR. For the other tree codes expmed.= cc has code how to adjust the TRUNC_MOD_EXPR into those by emitting some extra comparisons and conditional updates. Similarly for *_DIV_EXPR, except in that case it actually needs both division and modulo. While it would be possible to handle it in expmed.cc for vectors as wel= l, we'd need to be sure all the vector operations we need for that are available, and furthermore we wouldn't account for that in the costing. So, IMHO it is better to stop pretending those non-truncating (and non-exact) div/mod operations have an optab. For GCC 13, we should IMHO pattern match these in tree-vect-patterns.cc and transform them to truncating div/mod with follow-up adjustments and let the vectorizer vectorize that. As written in the PR, for signed operands: r =3D x %[fl] y; is r =3D x % y; if (r && (x ^ y) < 0) r +=3D y; and d =3D x /[fl] y; is r =3D x % y; d =3D x / y; if (r && (x ^ y) < 0) --d; and r =3D x %[cl] y; is r =3D x % y; if (r && (x ^ y) >=3D 0) r -=3D y; and d =3D /[cl] y; is r =3D x % y; d =3D x / y; if (r && (x ^ y) >=3D 0) ++d; (too lazy to figure out rounding div/mod now). I'll create a PR for that. The patch also extends a match.pd optimization that floor_mod on unsigned operands is actually trunc_mod. 2022-01-19 Jakub Jelinek PR middle-end/102860 * match.pd (x %[fl] y -> x % y): New simplification for unsigned integral types. * optabs-tree.c (optab_for_tree_code): Return unknown_optab for {CEIL,FLOOR,ROUND}_{DIV,MOD}_EXPR with VECTOR_TYPE. * gfortran.dg/pr102860.f90: New test. (cherry picked from commit ffc7f200adbdf47f14b3594d9b21855c19cf797a)=