From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 813B73895FE3; Fri, 21 Jun 2024 11:19:21 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 813B73895FE3 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1718968761; bh=hUre7wybcPJqJrPG7qlCL93Huujq0uVtagwH5eRu3+s=; h=From:To:Subject:Date:In-Reply-To:References:From; b=sO2j8H9cJDHFKwTJQYK7vY+VL+dzYfD2nP9O72ZOMWbk2bm0k3yOIbOuQlBBy1Y1S Pvsfg4fVTSBgyzO1m/HA8TEyzCYBuqNt/3BJtLmVRjmgRpG2cwZIPWRZNTtnk3xR4P 8GbKJtpsp0jpMnglCLNBNiwUYbIBgnCxebzlFt9M= From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/115528] [15 regression] segmentation fault in legacy F77 code since r15-1238-g1fe55a1794863b Date: Fri, 21 Jun 2024 11:19:21 +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: 15.0 X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org X-Bugzilla-Target-Milestone: 15.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc 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=3D115528 Richard Biener changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rsandifo at gcc dot gnu.org --- Comment #22 from Richard Biener --- Creating dr for aa[_13] analyze_innermost: success. base_address: &aa offset from base address: (ssizetype) ((sizetype) i_35 * 8) constant offset from base address: -8 step: 32 base alignment: 16 base misalignment: 0 offset alignment: 8 step alignment: 32 base_object: aa Access function 0: {{0, +, 1}_1, +, 4}_2 but somehow we computed dr_info->misalignment of zero and thus we classify this as dr_aligned. Previously the gap code disqualified SLP use and avoided this latent issue. t.f:14:12: note: inner step divides the vector alignment. t.f:14:12: missed: misalign =3D 0 bytes of ref aa[_13] it's a bit odd - vect_compute_data_ref_alignment does innermost_loop_behavior *drb =3D vect_dr_behavior (vinfo, dr_info); but vect_dr_behavior in this case returns &STMT_VINFO_DR_WRT_VEC_LOOP (stmt_info) because the access is in the inner loop: if (loop_vinfo =3D=3D NULL || !nested_in_vect_loop_p (LOOP_VINFO_LOOP (loop_vinfo), stmt_info)) return &DR_INNERMOST (dr_info->dr); else return &STMT_VINFO_DR_WRT_VEC_LOOP (stmt_info); with respect to the outer loop the access is computed misaligned through step_alignment $8 =3D {base_address =3D ,=20 offset =3D , init =3D ,=20 step =3D , base_alignment =3D 16,=20 base_misalignment =3D 0, offset_alignment =3D 128, step_alignment =3D 8} and misaligned with respect to the inner loop via offset_alignment: $12 =3D {base_address =3D ,=20 offset =3D , init =3D ,=20 step =3D , base_alignment =3D 16,=20 base_misalignment =3D 0, offset_alignment =3D 8, step_alignment =3D 32} but we seem to only look at offset_alignment of one and step_alignment of the other data piece. It seems to me the innermost behavior should cover the outer step via offset_alignment (but maybe I'm wrong). Still this seems to be a quite old issue. It seems to me we have to consider both for the nested case, thus the 'else' arm should be unconditional and use 'drb'. I'm testing a patch.=