[Bug fortran/105205] New: Incorrect assignment of derived type with allocatable, deferred-length character component

[Bug fortran/105205] New: Incorrect assignment of derived type with allocatable, deferred-length character component

[townsend at astro dot wisc.edu]

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

            Bug ID: 105205
           Summary: Incorrect assignment of derived type with allocatable,
                    deferred-length character component
           Product: gcc
           Version: 11.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: townsend at astro dot wisc.edu
  Target Milestone: ---

I've run into problems with assignment of derived types containing an
allocatable array of deferred-length strings. Example program:

---
program alloc_char_type
   implicit none
   type mytype
      character(:), allocatable :: c(:)
   end type mytype
   type(mytype) :: a
   type(mytype) :: b
   integer :: i
   a%c = ['foo','bar','biz','buz']
   b = a
   do i = 1, size(b%c)
      print *,b%c(i)
   end do
end
---

Running with gfortran 10.2.0 or 11.2.0, I get the output:

>>
 foo



<<

If I hard-code the length of the c component (to, say, 3), I get the expected
output:

>>
 foo
 bar
 biz
 buz
<<

It seems as if only the first element of c is being copied correctly.

cheers,

Rich

[Bug fortran/105205] Incorrect assignment of derived type with allocatable, deferred-length character component

[pault at gcc dot gnu.org]

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

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

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

--- Comment #1 from Paul Thomas <pault at gcc dot gnu.org> ---
Hi Rich,

Thanks for the report.

I have just worked up a fix for a number of associate bugs that involve
deferred length components, which also seems to put eliminate your problem.

I'll add your testcase.

Cheers

Paul

[Bug fortran/105205] Incorrect assignment of derived type with allocatable, deferred-length character component

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Paul Thomas <pault@gcc.gnu.org>:

https://gcc.gnu.org/g:eac493851f07df98213ecf67a5e9ab41a7babcd2

commit r13-7121-geac493851f07df98213ecf67a5e9ab41a7babcd2
Author: Paul Thomas <pault@gcc.gnu.org>
Date:   Sat Apr 8 09:04:13 2023 +0100

    Fortran: Fix some of the bugs in associate [PR87477]

    2023-04-08  Paul Thomas  <pault@gcc.gnu.org>

    gcc/fortran
            PR fortran/87477
            * iresolve.cc (gfc_resolve_adjustl, gfc_resolve_adjustr): if
            string length is deferred use the string typespec for result.
            * resolve.cc (resolve_assoc_var): Handle parentheses around the
            target expression.
            (resolve_block_construct): Remove unnecessary static decls.
            * trans-array.cc (gfc_conv_expr_descriptor): Guard string len
            expression in condition. Improve handling of string length and
            span, especially for substrings of the descriptor.
            (duplicate_allocatable): Make element type more explicit with
            'eltype'.
            * trans-decl.cc (gfc_get_symbol_decl): Emit a fatal error with
            appropriate message instead of ICE if symbol type is unknown.
            (gfc_generate_function_code): Set current locus to proc_sym
            declared_at.
            * trans-expr.cc (gfc_get_expr_charlen): Retain last charlen in
            'previous' and use if end expression in substring reference is
            null.
            (gfc_conv_string_length): Use gfc_conv_expr_descriptor if
            'expr_flat' is an array. Add post block to catch deallocation
            of temporaries.
            (gfc_conv_procedure_call): Assign the parmse string length to
            the expression string length, if it is deferred.
            (gfc_trans_alloc_subarray_assign): If this is a deferred string
            length component, store the string length in the hidden comp.
            Update the typespec length accordingly. Generate a new type
            spec for the call to gfc_duplicate-allocatable in this case.
            * trans-io.cc (gfc_trans_transfer): Scalarize transfer of
            deferred character array components.

    gcc/testsuite/
            PR fortran/87477
            * gfortran.dg/associate_47.f90 : Enable substring test.
            * gfortran.dg/associate_51.f90 : Update an error message.
            * gfortran.dg/goacc/array-with-dt-2.f90 : Add span to
            uninitialzed dg-warnings.

            PR fortran/85686
            PR fortran/88247
            PR fortran/91941
            PR fortran/92779
            PR fortran/93339
            PR fortran/93813
            PR fortran/100948
            PR fortran/102106
            * gfortran.dg/associate_60.f90 : New test

            PR fortran/98408
            * gfortran.dg/pr98408.f90 : New test

            PR fortran/105205
            * gfortran.dg/pr105205.f90 : New test

            PR fortran/106918
            * gfortran.dg/pr106918.f90 : New test

[Bug fortran/105205] Incorrect assignment of derived type with allocatable, deferred-length character component

[pault at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #3 from Paul Thomas <pault at gcc dot gnu.org> ---
Fixed on mainline

Thanks for the report

Paul