Reduced test for gfortran.dg/transfer_intrinsic_3.f90

module m
  implicit none
contains
  pure function str_vs(vs) result(s)
    character, dimension(:), intent(in) :: vs
    character(len=size(vs)) :: s
    s = transfer(vs, s)
  end function str_vs
end module m

  use m
  implicit none
  character, dimension(:), pointer :: QName
  character :: tmp(6)
  integer :: n
  allocate(qname(6))
  qname = (/ 'a','b','c','d','e','f' /)

  tmp = str_vs(qname(1:n-1))
  print *, tmp
end

transfer_intrinsic_3_red.f90: In function 'MAIN__':
transfer_intrinsic_3_red.f90:19:0: internal compiler error: in lhd_incomplete_type_error, at langhooks.c:203
   tmp = str_vs(qname(1:n-1))

Note that the test compiles, but generates a wrong code, without the module:

  implicit none
  character, dimension(:), pointer :: QName
  character :: tmp(6)
  integer :: n
  allocate(qname(6))
  qname = (/ 'a','b','c','d','e','f' /)

  tmp = str_vs(qname(1:n-1))
  print *, tmp
contains
  pure function str_vs(vs) result(s)
    character, dimension(:), intent(in) :: vs
    character(len=size(vs)) :: s
    s = transfer(vs, s)
  end function str_vs
end

Reduced test for gfortran.dg/proc_decl_23.f90

module m_string

  type t_string
    procedure(string_to_char), pointer, nopass :: char3 ! segfault
  end type t_string

contains

  function string_to_char (s) result(res)
    character, dimension(:), intent(in) :: s
    character(len=size(s)) :: res
    do i = 1, size(s)
      res(i:i) = s(i)
    end do
  end function string_to_char

end module m_string

  use m_string
  type(t_string) :: t
  print *, string_to_char (["a","b","c"])
end

If 'print *, string_to_char (["a","b","c"])' is commented in the original test, it compiles and passes.

I also confirm that if the "contains ..." is moved from the module to the program, the tests compile and run without error for gfortran.dg/auto_char_len_3.f90 andproc_decl_23.f90.

I thought the following would work. While it does so for the test cases, it causes new failures. In principle, not elem_len but "dim[0].sm" is the correct value - assuming, it is set.

--- a/gcc/fortran/trans-array.c
+++ b/gcc/fortran/trans-array.c
@@ -424,3 +424,2 @@ gfc_conv_descriptor_stride_get (tree desc, tree dim)
-  tmp = gfc_get_element_type (type);
-  size = size_in_bytes (tmp);
-  size = fold_convert (gfc_array_index_type, size);
+  size = fold_convert (gfc_array_index_type,
+                      gfc_conv_descriptor_elem_len_get (desc));
@@ -442,2 +441,2 @@ gfc_conv_descriptor_stride_set (stmtblock_t *block, tree desc,
-  tmp = gfc_get_element_type (TREE_TYPE (desc));
-  tmp = size_in_bytes (tmp);
+  tmp = fold_convert (gfc_array_index_type,
+                     gfc_conv_descriptor_elem_len_get (desc));

That should now be fixed since the commit http://gcc.gnu.org/r198688 / http://gcc.gnu.org/ml/fortran/2013-05/msg00031.html

(I think some other patches before also contributed to this fix.)


(In reply to comment #1)
> Note that the test compiles, but generates a wrong code, without the module:

I think it works - but I am too lazy to look through the test case to understand whether it indeed works.

For the record, the first test in comment #1 is invalid as n is not initialized. Now I see something I don't expect for both trunk and fortran-dev: if I set n to 7, then printing tmp gives 'aaaaaa'. Is this expected?
If yes, why? If no, should I open a PR for it?

(In reply to comment #5)
> For the record, the first test in comment #1 is invalid as n is not
> initialized. Now I see something I don't expect for both trunk and fortran-dev:
> if I set n to 7, then printing tmp gives 'aaaaaa'. Is this expected?

Yes, it is:
   str_vs(qname(1:n-1))
returns the string "abcdef" which is then assigned to the len=1 array "tmp":
  tmp = "abcdef"
as tmp is only len=1, only "a" is assigned - to all elements of the size=6 array:
  character :: tmp(6)

I assume you misread it as:
    character :: tmp*6
or as
    character(len=6) :: tmp

> as tmp is only len=1, only "a" is assigned

Thanks for the explanation. I missed the fact that len=1 for tmp(i).