[Bug fortran/108581] New: wrong assignment on two-rank array with deferred-length characters

[Bug fortran/108581] New: wrong assignment on two-rank array with deferred-length characters

[saitofuyuki at jamstec dot go.jp]

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

            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 = 0, xmax = 0
  integer,parameter :: ymin = 0, ymax = 1
  integer,parameter :: l = 2

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

  integer x, y

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

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

  do y = ymin, ymax
     write(*, *) '(1) ', y,  (a(x, y), x = 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.

[Bug fortran/108581] wrong assignment on two-rank array with deferred-length characters

[saitofuyuki at jamstec dot go.jp]

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

--- Comment #1 from saitofuyuki at jamstec dot go.jp ---
Created attachment 54365
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54365&action=edit
compiler output

command to compile:

% gfortran -O0 -Wall -v -save-temps dtest.f90

[Bug fortran/108581] wrong assignment on two-rank array with deferred-length characters

[pault at gcc dot gnu.org]

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

Paul Thomas <pault at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2023-03-28
                 CC|                            |pault at gcc dot gnu.org

--- Comment #2 from Paul Thomas <pault at gcc dot gnu.org> ---
Dear Saito-san,

Thank you for the report. Confirmed on 13.0.1.

The fault persists even when the limits are changed (I thought that the zeros
might be the cause of the problem).

Regards

Paul

For the record, the error occurs in creating the array descriptor for the
transfer to the library write function:
            {
              integer(kind=8) D.4307;
              integer(kind=8) D.4308;
              integer(kind=8) D.4309;
              struct array01_character(kind=1) parm.12;
              integer(kind=8) D.4316;

              _F.a = _F.a;
              D.4307 = a.dim[0].lbound;
              D.4308 = a.dim[0].ubound;
              D.4309 = (integer(kind=8)) y;
              parm.12.span = NON_LVALUE_EXPR <_F.a>;
              parm.12.dtype = {.elem_len=(unsigned long) _F.a, .rank=1,
.type=6};
              D.4316 = a.dim[0].stride;
              parm.12.dim[0].lbound = 1;
              parm.12.dim[0].ubound = (1 - D.4307) + D.4308;
              parm.12.dim[0].stride = NON_LVALUE_EXPR <D.4316>;
              parm.12.data = a.data + (sizetype) (((D.4307 - a.dim[0].lbound) *
D.4316 + (D.4309 - a.dim[1].lbound) * a.dim[1].stride) * (integer(kind=8))
SAVE_EXPR <D.4318>);
              parm.12.offset = -NON_LVALUE_EXPR <D.4316>;
              _gfortran_transfer_array_write (&dt_parm.11, &parm.12, 1, _F.a);
            }

I suspect that SAVE_EXPR <D.4318> is returning zero so that the data pointer is
independent of y. The first write statement scalarizes the operation and makes
use of the 'span' field of 'a', rather than D.4318.