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

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80945

Paul Thomas  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #13 from Paul Thomas  ---
Fixed on trunk.

Thanks for the report.

Paul and Thomas

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

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80945

--- Comment #12 from Dominique d'Humieres  ---
Fixed?

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

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80945

--- Comment #11 from Thomas Koenig  ---
Author: tkoenig
Date: Mon Feb 19 18:21:45 2018
New Revision: 257814

URL: https://gcc.gnu.org/viewcvs?rev=257814=gcc=rev
Log:
2018-02-19  Thomas Koenig  

PR fortran/35339
* frontend-passes.c (traverse_io_block): Remove workaround for
PR 80945.

2018-02-19  Thomas Koenig  

PR fortran/35339
* gfortran.dg/implied_do_io_4.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/implied_do_io_4.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/frontend-passes.c
trunk/gcc/testsuite/ChangeLog

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

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80945

--- Comment #10 from Paul Thomas  ---
Author: pault
Date: Sun Feb 18 08:59:06 2018
New Revision: 257788

URL: https://gcc.gnu.org/viewcvs?rev=257788=gcc=rev
Log:
2018-02-18  Paul Thomas  

PR fortran/80945
* trans-array.c (gfc_conv_expr_descriptor): Set parmtype from
the typenode in the case of deferred length characters.

2018-02-18  Paul Thomas  

PR fortran/80945
* gfortran.dg/associate_35.f90: Remove error, add stop n's and
change to run.


Added:
trunk/gcc/testsuite/gfortran.dg/deferred_character_19.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-array.c
trunk/gcc/testsuite/ChangeLog

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

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80945

Paul Thomas  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org

--- Comment #9 from Paul Thomas  ---
Created attachment 43438
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43438=edit
A demo patch for the PR

This does the job but sucks stylistically. I will sort out something better.

It does regtest fine, though :-) It also fixes:

program main
implicit none
integer:: i
integer, parameter:: N = 10
character(len=:), dimension(:),allocatable:: ca
character(len=:), dimension(:,:),allocatable:: cb
allocate(character(len=N) :: ca(3))
ca(1) = "foo"
ca(2) = "bar"
ca(3) = "xyzzy"
write (*, '(3A5)') ca(1:3)
allocate(character(len=N) :: cb(3,2))
cb(1,1) = "foo"
cb(2,1) = "bar"
cb(3,1) = "xyzzy"
write (*, '(3A5)') cb(1:3,1) ! Hence the assignment of the rank!  
end program

Paul

[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  ---
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
 wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80945
>
> --- Comment #7 from Thomas Koenig  ---
> 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 (_parm.1);
>   {
> struct array01_unknown parm.2;
>
> parm.2.dtype = {.elem_len=(unsigned long) SAVE_EXPR , .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 (_parm.1, , 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.

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

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80945

--- Comment #7 from Thomas Koenig  ---
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 (_parm.1);
  {
struct array01_unknown parm.2;

parm.2.dtype = {.elem_len=(unsigned long) SAVE_EXPR , .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 (_parm.1, , 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?

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

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80945

--- Comment #6 from Thomas Koenig  ---
If this patch is fixed, please remember to remove the extra
check in frontend-passes.c (traverse_io_block). Just grep
for 80945.

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

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80945

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org
 Depends on||68241

--- Comment #5 from Dominique d'Humieres  ---
The code is correctly compiled if I replace

character(len=:), dimension(:),allocatable:: ca

with

character(len=N), dimension(:),allocatable:: ca

or

read (buffer, '(3A5)') ca(1:3)

with

read (buffer, '(3A5)') ca

It could be related to pr68241.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68241
[Bug 68241] [meta-bug] [F03] Deferred-length character

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

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80945

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #4 from Jerry DeLisle  ---
(In reply to Thomas Koenig from comment #3)
> Really strange - the tree dumps look OK at first glance.
> 

Maybe missing something in a backend declaration?

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

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80945

--- Comment #3 from Thomas Koenig  ---
Really strange - the tree dumps look OK at first glance.

  D.3543 = (sizetype) NON_LVALUE_EXPR <.ca>;

and later on

parm.3.dtype = ((integer(kind=8)) SAVE_EXPR  << 6) + 49;
parm.3.dim[0].lbound = 1;
parm.3.dim[0].ubound = 3;
parm.3.dim[0].stride = 1;
parm.3.data = (void *) &(*(character(kind=1)[0:][1:.ca] * restrict)
ca.data)[1 - ca.dim[0].lbound];
parm.3.offset = 0;
_gfortran_transfer_array_write (_parm.2, , 1, .ca);

What am I missing?

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

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80945

Thomas Koenig  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-06-01
 Ever confirmed|0   |1

--- Comment #2 from Thomas Koenig  ---
The dtype is messed up.  Breaking at _gfortran_transfer_array
for the test case in cmment #1 shows

Breakpoint 1, _gfortran_transfer_array (dtp=0x7fffd910,
desc=0x7fffdaf0, kind=1, charlen=10) at
../../../gcc-7/libgfortran/io/transfer.c:2409
2409  if ((dtp->common.flags & IOPARM_LIBRETURN_MASK) !=
IOPARM_LIBRETURN_OK)
(gdb) p *desc
$3 = {base_addr = 0x605ff0 "foo   bar   xyzzy ", offset =
18446744073709551615, dtype = 689, dim = {{_stride = 1, lower_bound = 1,
_ubound = 3}, {_stride = 8241976683187367782, 
  lower_bound = 2340036147838197792, _ubound = 2314885530818453536},
{_stride = 2314885530818453536, lower_bound = 2314885530818453536, _ubound =
2314885530818453536}, {_stride = 8224, 
  lower_bound = 44024187392, _ubound = 140737488346016}, {_stride = 0,
lower_bound = 4196368, _ubound = 140737488346240}, {_stride = 140737488346016,
lower_bound = 4197718, 
  _ubound = 140737488346248}, {_stride = 4294967296, lower_bound = 4197728,
_ubound = 140737336403265}}}
(gdb) c
Continuing.
foo  bar  xyzzy

Breakpoint 1, _gfortran_transfer_array (dtp=0x7fffd910,
desc=0x7fffd8e0, kind=1, charlen=10) at
../../../gcc-7/libgfortran/io/transfer.c:2409
2409  if ((dtp->common.flags & IOPARM_LIBRETURN_MASK) !=
IOPARM_LIBRETURN_OK)
(gdb) p *desc
$4 = {base_addr = 0x605ff0 "foo   bar   xyzzy ", offset = 0, dtype
= -60931979599, dim = {{_stride = 1, lower_bound = 1, _ubound = 3}, {_stride =
25769807872, lower_bound = 4198108, 
  _ubound = 13}, {_stride = 0, lower_bound = 0, _ubound = 0}, {_stride = 0,
lower_bound = 0, _ubound = 0}, {_stride = 4198114, lower_bound = 5, _ubound =
0}, {_stride = 0, lower_bound = 0, 
  _ubound = 0}, {_stride = 0, lower_bound = 0, _ubound = 0}}}

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

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80945

--- Comment #1 from Thomas Koenig  ---
1. write also fails (no surprise there)
2. ca is OK, ca(1:3) is not.

$ cat u.f90
program main
implicit none
integer:: i
integer, parameter:: N = 10
character(len=:), dimension(:),allocatable:: ca
character(len=50):: buffer
allocate(character(len=N):: ca(3))
buffer = "foo  bar  xyzzy"
ca(1) = "foo"
ca(2) = "bar"
ca(3) = "xyzzy"
write (*, '(3A5)') ca
write (*, '(3A5)') ca(1:3)
end program

$ gfortran u.f90 && ./a.out
foo  bar  xyzzy

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x7f38e528406f in ???
#1  0x7f38e5384440 in ???
#2  0x7f38e5eeb67c in formatted_transfer_scalar_write
at ../../../gcc-7/libgfortran/io/transfer.c:2059
#3  0x7f38e5eeb81c in formatted_transfer
at ../../../gcc-7/libgfortran/io/transfer.c:2279
#4  0x400d03 in ???
#5  0x400d55 in ???
#6  0x7f38e526f540 in ???
#7  0x400839 in ???
at ../sysdeps/x86_64/start.S:120
#8  0x in ???
Speicherzugriffsfehler (Speicherabzug geschrieben)