[Bug fortran/80945] Invalid code with allocatable character array in READ/WRITE statement

[paul.richard.thomas at gmail dot com]

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-bugzilla@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.