Bug 50221 - Allocatable string length fails with array assignment
Allocatable string length fails with array assignment
Status: NEW
Product: gcc
Classification: Unclassified
Component: fortran
4.6.0
: P3 normal
: ---
Assigned To: Not yet assigned to anyone
: wrong-code
Depends on:
Blocks: 45170
  Show dependency treegraph
 
Reported: 2011-08-28 16:08 UTC by Clive Page
Modified: 2013-06-16 14:31 UTC (History)
0 users

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2013-06-16 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Clive Page 2011-08-28 16:08:16 UTC
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
Comment 1 Tobias Burnus 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.
Comment 2 Tobias Burnus 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
Comment 3 Dominique d'Humieres 2013-06-16 14:31:38 UTC
Still present at revision 200128.