From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 42D643896C30; Mon, 5 Dec 2022 19:12:22 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 42D643896C30 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1670267542; bh=pdfVxQRDpnG2yz4zF14ErgaDphCtKaHN905q/1x16QQ=; h=From:To:Subject:Date:In-Reply-To:References:From; b=XwBGaTwIkQMEcBkPE0D1vxD/W7eEAh+CeM4i1QLKyQFjCuujTdIBcP0qVflrGmxWC z+8nfbB2AmkSmVKX951cXMxoh1I5FN2f27WKoXgHUoyjEtM0jUvHF1EQul972uWzwI aknmxGYdI/nEgoADNzQrZW+wmG+7Gz6WHDz0Q+bU= From: "anlauf at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/107968] array slicing gives wrong result for an array pointer defined in a subroutine Date: Mon, 05 Dec 2022 19:12:22 +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: 12.2.0 X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: anlauf 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 everconfirmed bug_status 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=3D107968 anlauf at gcc dot gnu.org changed: What |Removed |Added ---------------------------------------------------------------------------- Last reconfirmed| |2022-12-05 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC| |anlauf at gcc dot gnu.org --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed. A look at the tree dump shows a funny expansion of the array section in the data transfer (write statement). It appears that some optimization of the transfer of arrays is attempted, but the stride looks wrong. Replacing WRITE (0,*) vertices_pointer%vlon(1:) by any of the following produces different - working - output: WRITE (0,*) [vertices_pointer%vlon(1:)] WRITE (0,*) (vertices_pointer%vlon(1:)) WRITE (0,*) (vertices_pointer%vlon(i),i=3D1,size(vertices_pointer%vlon)) And - as reported - why should the addition of a (dead) pointer assignment after the write change the way the array section is expanded? Looking at older gfortran version, all tested seem to fail. And with the dead pointer assignment uncommented, gfortran-7 ICEs.=