From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id D209C3841886; Tue, 25 Jun 2024 12:30:21 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D209C3841886 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1719318621; bh=rvFBR8aCZFanGrDxAVqaEpWgt+CuVr1soo7OvlRvc+s=; h=From:To:Subject:Date:In-Reply-To:References:From; b=SNnaYJBOxscB1/uFJuw7kPzdwHAFFoHDnphX/nQ8+72FNw+xufnAsfwFbVI79qIXX FCkrLhHFOXemyGzlC9CR0tKs+oqlIrFSEiDWVXc8XdouOnaV4eG6lPxP6gwQiMuru3 jUntUFn3rapwYGWzRYEEQ9yUmZ4Ef6Sxuylauqd0= From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/115640] GCN: FAIL: gfortran.dg/vect/pr115528.f -O execution test Date: Tue, 25 Jun 2024 12:30:20 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 15.0 X-Bugzilla-Keywords: testsuite-fail X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cf_reconfirmed_on bug_status cc everconfirmed 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=3D115640 Richard Biener changed: What |Removed |Added ---------------------------------------------------------------------------- Last reconfirmed| |2024-06-25 Status|UNCONFIRMED |NEW CC| |rsandifo at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- It doesn't look like a misaligned access at least. Instead it looks like an out-of-bound access? OTOH I probably missed the fortran equivalent of #include "tree-vect.h" and check_vect() in main. We do vectorize the outer loop, but with partial vectors (huh, it iterates exactly 4 times). I'm not exactly sure the outer loop mask is the correct one to use in the inner loop though (but we do that). And this might expla= in the issue - we're definitely accessing excess elements of AA in the inner loop. In particular we disallowed grouped accesses in inner loops but this load is basically treated as a grouped access by means of having a load permutation. Test coverage seems to be weak here and this restriction should be lifted ideally (I remember issues with the IV update, but that only was for the multiple-types case which is rejected separately). I'm not sure how one would deal with an outer .WHILE_ULT loop mask in the inner loop. This is AA(I,J) with I evolving in the outer loop and J in the inner loop. The outer loop evolution is contiguous, the inner loop evolution applies a stride of four. If you force GCN to use fixed length vectors (how?), does it work? How's it behaving on aarch64 with SVE? (the CI was happy, but maybe doesn't enable SVE) Confirmed as in, it looks like wrong generated code.=