https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80945
--- Comment #8 from paul.richard.thomas at gmail dot com <paul.richard.thomas at gmail dot com> --- Hi Thomas, It doesn't just ring bells, it lets off sirens and sets the marching bands to marching! I can only find rather old sources on the web but I seem to remember that the new dtype generation uses gfc_get_element_type , which makes use of GFC_TYPE_ARRAY_DATAPTR_TYPE. If this latter does not get reset with each reallocation it would be the source of the trouble. I'll try to take a look tonight, although the 14th February might prevail :-) Paul On 13 February 2018 at 21:18, tkoenig at gcc dot gnu.org <gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80945 > > --- Comment #7 from Thomas Koenig <tkoenig at gcc dot gnu.org> --- > Still fails with current trunk. > > Code from comment#1, somewhat simplified: > > program main > implicit none > integer:: i > integer, parameter:: N = 10 > character(len=:), dimension(:),allocatable:: ca > allocate(character(len=N):: ca(3)) > ca(1) = "foo" > ca(2) = "bar" > ca(3) = "xyzzy" > write (*, '(3A5)') ca(1:3) > end program > > This yields on gcc110: > > foo foo foo > > Looking at the tree dump, we see > > MAIN__ () > { > integer(kind=8) .ca; > struct array01_unknown ca; > bitsizetype D.2078; > sizetype D.2079; > > D.2078 = (bitsizetype) (sizetype) NON_LVALUE_EXPR <.ca> * 8; > D.2079 = (sizetype) NON_LVALUE_EXPR <.ca>; > > and later > > { > integer(kind=4) overflow.0; > > .ca = 10; > ca.dtype = {.elem_len=(unsigned long) SAVE_EXPR <(sizetype) > NON_LVALUE_EXPR > <.ca>>, .rank=1, .type=6}; > > ... > > _gfortran_st_write (&dt_parm.1); > { > struct array01_unknown parm.2; > > parm.2.dtype = {.elem_len=(unsigned long) SAVE_EXPR <D.2079>, .rank=1, > .type=6}; > parm.2.dim[0].lbound = 1; > parm.2.dim[0].ubound = 3; > parm.2.dim[0].stride = 1; > parm.2.data = (void *) &(*(character(kind=1)[0:][1:.ca] * restrict) > ca.data)[1 - ca.dim[0].lbound]; > parm.2.offset = ca.offset; > _gfortran_transfer_array_write (&dt_parm.1, &parm.2, 1, .ca); > > so the dtype gets its elem_len from the uninitialized copy of .ca > instead of the correctly initialized value later. > > Paul, does this ring any bells? > > -- > You are receiving this mail because: > You are on the CC list for the bug.
