[Bug fortran/50221] New: Allocatable string length fails with array assignment

[Bug fortran/50221] New: Allocatable string length fails with array assignment

[clivegpage at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50221

             Bug #: 50221
           Summary: Allocatable string length fails with array assignment
    Classification: Unclassified
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: clivegpage@gmail.com


The program below:

program testalloc
implicit none
character(:), allocatable, dimension(:) :: array
array = (/'xx', 'yy', 'zz'/)
print *, 'array=', array, len(array(1)), size(array)
end program

Should print out something like:
 array=xxyyzz           2           3
but with gfortran (v4.6.0) I get
 array=zzzzzz           2           3

[Bug fortran/50221] Allocatable string length fails with array assignment

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50221

Tobias Burnus <burnus at gcc dot gnu.org> changed:

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

--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-08-29 07:32:18 UTC ---
Unfortunately, there are still some issues with deferred-length character
strings - including arrays; see also bug 45170 comment 9.

[Bug fortran/50221] Allocatable string length fails with array assignment

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50221

--- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-05-12 12:10:33 UTC ---
The following program illustrates some of the problems:

a) If the comment lines are removed (i.e. a module is used), there is no
valgrind failure and the result is correct. (Note: It requires the patch from
PR 53329 with "ns" replaced by "sym->ns".)

b) The program (as is) shows no valgrind failure, but the assignment is wrong:
"c3", "c3", "c3" instead of "a1", "b2", "c3".

c) If one removes the "save,", the result is as with (b) but valgrind shows
many errors of the form:
  Conditional jump or move depends on uninitialised value(s)
    at 0x4C2C3A9: memcpy@@GLIBC_2.14
(The same failures one gets for the original program of comment 0.)


Looking at the dump for (b) - also in comparison with (a) -, I fail to see why
one get's ["c1","c1","c1"] - the code looks correct ("S.0" goes from 1 to 3):

 __builtin_memcpy ((void *) &(*D.1881)[(S.0 + D.1885) + D.1882],
                   (void *) &const[S.0 + -1], (unsigned long) D.1887);

In principle, accessing the second argument wrongly should cause that problem.
But that one looks okay. I wonder more about the left as
   (*D.1881)[...]
assumes that the compiler knows the size of one element - I am not sure that
that works as ".str" is not yet the right value before the line:

    character(kind=1)[0:][1:.str] * restrict D.1881;


!module m
  character(len=:), save, allocatable :: str(:)
  character(len=2), parameter :: const(3) = ["a1", "b2", "c3"]
!end
!use m
call test()
if(allocated(str)) deallocate(str)
contains
subroutine test()
  call doit()
  print *, 'strlen=',len(str),' / array size =',size(str)
  print '(3a)', '>',str(1),'<'
  print '(3a)', '>',str(2),'<'
  print '(3a)', '>',str(3),'<'
end subroutine test
subroutine doit()
    str = const
end subroutine doit
end

[Bug fortran/50221] Allocatable string length fails with array assignment

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50221

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-06-16
     Ever confirmed|0                           |1

--- Comment #3 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Still present at revision 200128.