[Bug fortran/101871] New: Array of strings of different length passed as an argument produces invalid result.

[Bug fortran/101871] New: Array of strings of different length passed as an argument produces invalid result.

[david.sagan at gmail dot com]

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

            Bug ID: 101871
           Summary: Array of strings of different length passed as an
                    argument produces invalid result.
           Product: gcc
           Version: og10 (devel/omp/gcc-10)
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: david.sagan at gmail dot com
  Target Milestone: ---

Consider the test program:

program tao_program

implicit none
integer i
character(80) abc(9)
character(40) name

name = 'abasdfadsf'

abc = [character(80):: &
            'Beam parameters not computed at: ' // trim(name), &
            'Singular sigma matrix is:', &
            '  \6es15.7\', '  \6es15.7\', '  \6es15.7\', '  \6es15.7\', ' 
\6es15.7\', '  \6es15.7\', &
            'Will not print any more singular sigma matrices']

do i = 1, size(abc)
  print '(i6, 2x, a)', i, trim(abc(i))
enddo

call out_io_lines2 ([character(80):: &
        'Beam parameters not computed at: ' // trim(name), &
        'Singular sigma matrix is:', &
        '  \6es15.7\', '  \6es15.7\', '  \6es15.7\', '  \6es15.7\', ' 
\6es15.7\', '  \6es15.7\', &
        'Will not print any more singular sigma matrices'])

contains

subroutine out_io_lines2 (lines)

implicit none
character(*) lines(:)
integer i

do i = 1, size(lines)
  print '(i6, 2x, a)', i, trim(lines(i))
enddo

end subroutine out_io_lines2
end program



Now compile and run:
> gfortran tao_program.f90 
mac-mini-2:~/Bmad/test> ./a.out 
     1  Beam parameters not computed at: abasdfadsf
     2  Singular sigma matrix is:
     3    \6es15.7\
     4    \6es15.7\
     5    \6es15.7\
     6    \6es15.7\
     7    \6es15.7\
     8    \6es15.7\
     9  Will not print any more singular sigma matrices
     1  Beam parameters not computed at: abasdfadsf
     2  Singular sigma matrix is:
     3    \6es15.7\
     4    \6es15.7\
     5    \6es15.7\
     6    \6es15.7\
     7    \6es15.7\
     8    \6es15.7\
     9  Will not print any more singular sigma matr

Notice that the second "9" line is truncated. This should not be.

[Bug fortran/101871] Array of strings of different length passed as an argument produces invalid result.

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
                 CC|                            |kargl at gcc dot gnu.org
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2021-08-12

--- Comment #1 from kargl at gcc dot gnu.org ---
(In reply to David Sagan from comment #0)

> 
> call out_io_lines2 ([character(80):: &
>         'Beam parameters not computed at: ' // trim(name), &
>         'Singular sigma matrix is:', &
>         '  \6es15.7\', '  \6es15.7\', '  \6es15.7\', '  \6es15.7\', ' 
> \6es15.7\', '  \6es15.7\', &
>         'Will not print any more singular sigma matrices'])

For some reason, gfortran is ignoring the type-spec
in the array constructor of the actual argument if 
one uses the concatenation operator in the first
element of the constructor.  The length is set to
that of the first element.

This is going to be entertaining for whomever
takes on the challenge.  Here's a modified
test to consider

program tao_program

   implicit none

   integer i
   character(80) abc(9)
   character(40) name

   name = 'H'
   abc = [character(80) :: 'a'//trim(name), 'ab', 'abc', 'd', 'def', 'g', &
   &  'ghi', 'z', 'zy']

   call io([character(80) :: 'a'//trim(name), 'ab', 'abc', 'd', &
   &  'def', 'g', 'ghi', 'z', 'zyxwvut'])

   print *

   abc = [character(80) :: 'a', 'ab', 'abc', 'd'//trim(name), 'def', 'g', &
   &  'ghi', 'z', 'zy']

   call io([character(80) :: 'a', 'ab', 'abc', 'd'//trim(name), &
   &  'def', 'g', 'ghi', 'z', 'zyxwvut'])

   contains

      subroutine io (lines)
         implicit none
         character(*) lines(:)
         integer i
         do i = 1, size(lines)
            write(*,'(I0,A)') i, ' ' // trim(abc(i)) // ' ' // trim(lines(i))
         end do
      end subroutine io

end program

[Bug fortran/101871] Array of strings of different length passed as an argument produces invalid result.

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |anlauf at gcc dot gnu.org

--- Comment #2 from anlauf at gcc dot gnu.org ---
PR85547 is likely related to this one.

[Bug fortran/101871] Array of strings of different length passed as an argument produces invalid result.

[kargl at gcc dot gnu.org]

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

--- Comment #3 from kargl at gcc dot gnu.org ---
(In reply to anlauf from comment #2)
> PR85547 is likely related to this one.

Yes, indeed.  Looks like a duplicate.  I checked
that array.c(gfc_match_array_constructor) does the
right things.  So, someplace in the handling of
gfc_arglist, gfortran is overriding the typespec
set by the array with the typespec of the first
element if that element is an expression.

[Bug fortran/101871] Array of strings of different length passed as an argument produces invalid result.

[kargl at gcc dot gnu.org]

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

--- Comment #4 from kargl at gcc dot gnu.org ---
With this testcase,

program tao_program

   implicit none

   integer i
   character(80) abc(9)
   character(1) n

   n = 'H'
   abc = [character(80) :: &
   &  'a'//n, 'ab', 'abc', 'd', 'def', 'g', 'ghi', 'z', 'zyxwvut']

   call io([character(80) :: &
   &  'a'//n, 'ab', 'abc', 'd', 'def', 'g', 'ghi', 'z', 'zyxwvut'])

   contains

      subroutine io (lines)
         character(*) lines(:)
         integer i
         do i = 1, size(lines)
            write(*,'(I0,A)') i, ' ' // trim(abc(i)) // ' ' // trim(lines(i))
         end do
      end subroutine io

end program

I find that the actual argument is correctly parsed.

(gdb) p *tail->expr
$12 = {expr_type = EXPR_ARRAY, ts = {type = BT_CHARACTER, kind = 1, u = {
      derived = 0x803422870, cl = 0x803422870, pad = 54667376}, interface =
0x0, 
    is_c_interop = 0, is_iso_c = 0, f90_type = BT_UNKNOWN, deferred = false, 
    interop_kind = 0x7fffffffd950}, rank = 1, shape = 0x0, symtree = 0x0, ref =
0x0, where = {
    nextc = 0x803431c2c, lb = 0x803431be0}, base_expr = 0x0, is_snan = 0, error
= 0, 
  user_operator = 0, mold = 0, must_finalize = 0, no_bounds_check = 0,
external_blas = 0, 
  do_not_resolve_again = 0, do_not_warn = 0, from_constructor = 0,
representation = {
    length = 0, string = 0x0}, boz = {len = 0, rdx = 0, str = 0x0}, value = {
    logical = 54623680, iokind = 54623680, integer = {{_mp_alloc = 54623680,
_mp_size = 8, 
        _mp_d = 0x0}}, real = {{_mpfr_prec = 34414362048, _mpfr_sign = 0,
_mpfr_exp = 0, 
        _mpfr_d = 0x0}}, complex = {{re = {{_mpfr_prec = 34414362048,
_mpfr_sign = 0, 
            _mpfr_exp = 0, _mpfr_d = 0x0}}, im = {{_mpfr_prec = 0, _mpfr_sign =
0, 
            _mpfr_exp = 0, _mpfr_d = 0x0}}}}, op = {op = 54623680, uop = 0x0,
op1 = 0x0, 
      op2 = 0x0}, function = {actual = 0x803417dc0, name = 0x0, isym = 0x0,
esym = 0x0}, 
    compcall = {actual = 0x803417dc0, name = 0x0, base_object = 0x0, tbp = 0x0, 
      ignore_pass = 0, assign = 0}, character = {length = 34414362048, string =
0x0}, 
    constructor = 0x803417dc0}, param_list = 0x0}
(gdb) call debug(tail->expr)
(/ (// 'a' tao_program:n) , 'ab' , 'abc' , 'd' , 'def' , 'g' , 'ghi' , 'z' ,
'zyxwvut' /) (CHARACTER 80 1)
(gdb) call debug(tail->expr->ts)
(CHARACTER 80 1)

Both the elements and the typespec are set correctly.  So, when the
actual argument is evaluate the first element is (// 'a' tao_program:n)
which will have length of 2.  This is then used for all other elements.
Whoops.

[Bug fortran/101871] Array of strings of different length passed as an argument produces invalid result.

[anlauf at gcc dot gnu.org]

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

--- Comment #5 from anlauf at gcc dot gnu.org ---
In array.c:gfc_match_array_constructor there's the following code:

1335          /* Walk the constructor, and if possible, do type conversion for
1336             numeric types.  */
1337          if (gfc_numeric_ts (&ts))
1338            {
1339              m = walk_array_constructor (&ts, head);
1340              if (m == MATCH_ERROR)
1341                return m;
1342            }

Steve, you were the last one to work on this block.
It appears that non-numeric ts are not handled (here).
Can you give some insight?

[Bug fortran/101871] Array of strings of different length passed as an argument produces invalid result.

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #6 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Sun, Aug 15, 2021 at 07:21:42PM +0000, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101871
> 
> --- Comment #5 from anlauf at gcc dot gnu.org ---
> In array.c:gfc_match_array_constructor there's the following code:
> 
> 1335          /* Walk the constructor, and if possible, do type conversion for
> 1336             numeric types.  */
> 1337          if (gfc_numeric_ts (&ts))
> 1338            {
> 1339              m = walk_array_constructor (&ts, head);
> 1340              if (m == MATCH_ERROR)
> 1341                return m;
> 1342            }
> 
> Steve, you were the last one to work on this block.
> It appears that non-numeric ts are not handled (here).
> Can you give some insight?
> 

Unfortunately, I can't remember why it's confined to numeric
types.  I did the simply thing of commenting out the if-stmt
and got an ICE.  I also tried explicitly setting the typespec
of each array element to the typespec of array constructor
and that also ICE'd.

I haven't had time to polk further.  I think at some point the
actual arg list is reduced to a formal argument list.  This
might loose the array constructor typespec when reducing/resolving
the arg list.