From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 79EC63858D20; Sat, 28 Jan 2023 12:03:06 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 79EC63858D20
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1674907386;
	bh=Xjj8Uxxg0PM+tO8hpncyrpSZTk6IP/vRRvuEeBFLlBc=;
	h=From:To:Subject:Date:From;
	b=bbwYd4/GgxobYNj38yQ2dU1z7x8kAwsWL1y5YEZOTHQwMBxy5v7+C6sB90f9t2POD
	 CEiLA9zmx1FjJxMOilayiY8QexPEmhle4Y3H1haSysUicGNiI9GicwIPMiTyIMxWiP
	 2A0WZhwtpsiCDxsLBCjm3zBR2m7ZY7FbaLmsiJeQ=
From: "saitofuyuki at jamstec dot go.jp" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/108581] New: wrong assignment on two-rank array with
 deferred-length characters
Date: Sat, 28 Jan 2023 12:03:05 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 12.2.0
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: saitofuyuki at jamstec dot go.jp
X-Bugzilla-Status: UNCONFIRMED
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: bug_id short_desc product version bug_status
 bug_severity priority component assigned_to reporter target_milestone
Message-ID: <bug-108581-4@http.gcc.gnu.org/bugzilla/>
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: <gcc-bugs.sourceware.org>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D108581

            Bug ID: 108581
           Summary: wrong assignment on two-rank array with
                    deferred-length characters
           Product: gcc
           Version: 12.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: saitofuyuki at jamstec dot go.jp
  Target Milestone: ---

When a two-rank array with deferred-length characters is allocated,
reference of array sections fails at non-first elements.

Following is a minimum example to demonstlate it.
I tried several size on the second rank of the array (ymax).
All of the reference of a(:, ymin+1:) are failed.
Also, I tried several combination of the size of the first rank (xmin,
xmax), which all fail.

When with -O2 optimization, assignment seems to be already wrong.
gfortran-12.2.0, 11.3.0, 10.4.0, all show the same outputs.

----------------------------------------------------------------------
program dtest
  implicit none

  integer,parameter :: xmin =3D 0, xmax =3D 0
  integer,parameter :: ymin =3D 0, ymax =3D 1
  integer,parameter :: l =3D 2

  character(len=3D:),pointer     :: a(:, :) =3D> NULL()

  integer x, y

  allocate(character(len=3Dl)::a(xmin:xmax, ymin:ymax))

  a(:,:) =3D ' '
  a(xmin:xmax, ymin) =3D 'A.'
  a(xmin:xmax, ymax) =3D 'B.'

  do y =3D ymin, ymax
     write(*, *) '(1) ', y,  (a(x, y), x =3D xmin, xmax)
     write(*, *) '(2) ', y,  a(xmin:xmax, y)
     write(*, *) '(3) ', y,  a(:, y)
  enddo

  stop
end program dtest
----------------------------------------------------------------------
# expected outputs
 (1)            0 A.
 (2)            0 A.
 (3)            0 A.
 (1)            1 B.
 (2)            1 B.
 (3)            1 B.
----------------------------------------------------------------------
# outputs (-O0)
 (1)            0 A.
 (2)            0 A.
 (3)            0 A.
 (1)            1 B.
 (2)            1 A.
 (3)            1 A.
----------------------------------------------------------------------
# outputs (-O2)  even worse
 (1)            0 A.
 (2)            0 A.
 (3)            0 A.
 (1)            1 A.
 (2)            1 A.
 (3)            1 A.
----------------------------------------------------------------------

There are some similar reported bugs relating to deferred length
characters.  As far as I searched, however, all of them are reports on
derived types to have deferred-length characters.
What I found is not, so I just reported as a new bug.=