[Bug fortran/84155] [8 Regression] program hangs on valid code

[juergen.reuter at desy dot de]

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

--- Comment #23 from Jürgen Reuter  ---
All our code is fine also with this fix.

[Bug fortran/84155] [8 Regression] program hangs on valid code

[juergen.reuter at desy dot de]

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

--- Comment #22 from Jürgen Reuter  ---
I just started building r257550 of the trunk and will check our code. I'll
report back of there are any issues.

[Bug fortran/84155] [8 Regression] program hangs on valid code

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #21 from Paul Thomas  ---
Refixed following comment #18, for which thanks.

Although I retained the caching of the dtype in GFC_TYPE_ARRAY_DTYPE, I checked
that it is not used anywhere. I will try removing it altogether in the near
future.

Paul

[Bug fortran/84155] [8 Regression] program hangs on valid code

[pault at gcc dot gnu.org]

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

--- Comment #20 from Paul Thomas  ---
Author: pault
Date: Sat Feb 10 18:16:14 2018
New Revision: 257550

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

PR fortran/84141
PR fortran/84155
* trans-array.c (gfc_array_init_size): Revert the change made
in revision 257356 setting the dtype.
* trans-types.c (gfc_get_dtype): Do not use the cached dtype.
Call gfc_get_dtype_rank_type every time.

PR fortran/56691
* trans-array.c (gfc_conv_expr_descriptor): If the source array
is a descriptor type, use its offset, removing the condition
that is be a class expression.

2018-02-10  Paul Thomas  

PR fortran/56691
* gfortran.dg/type_to_class_4.f03: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/type_to_class_4.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-array.c
trunk/gcc/fortran/trans-types.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/84155] [8 Regression] program hangs on valid code

[pault at gcc dot gnu.org]

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

--- Comment #19 from Paul Thomas  ---
fferent types but who knows.
> 
> I suggest to remove the caching from gfc_get_dtype.

Indeed, it is the caching that is the source of the problem. I reverted the fix
and removed the caching from gfc_get_dtype; lo and behold, the problem was
gone.

I will investigate such use as there might be of the cached dtype before
committing any changes to trans-types.c but I rather suspect that this was an
underlying (cached?) bug waiting to hit us on the nose.

Thanks for pointing this out.

Paul

[Bug fortran/84155] [8 Regression] program hangs on valid code

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #18 from Richard Biener  ---
Hmm, I can only guess that you are running into a tree sharing issue?  We have

parm.21.dtype = {.elem_len=4, .rank=1, .type=1};
parm.21.dim[0].lbound = 1;
parm.21.dim[0].ubound = 1;
parm.21.dim[0].stride = 1;
parm.21.data = (void *) [0];
parm.21.offset = -1;
(*(struct array_t[0:] * restrict)
container.array.data)[container.array.offset + 1].child.dtype = {.elem_len=4,
.rank=1, .type=1};

but the time we arrive at gimplifying the latter it looks like

(*(struct array_t[0:] * restrict) container.array.data)[container.array.offset
+ 1].child.dtype = {}

in fact it looks like this already before the gimplifier does unshare_body ().

In fact the CONSTRUCTOR is cleared off its elements when gimplifying

array->_data->child.dtype = {.elem_len=4, .rank=1, .type=1}

which is in a whole different function!

Indeed gfc_get_dtype seems to cache this CONSTRUCTOR.  The gimplifier
generally unshares only things used multiple times in a single function
and destructively gimplifies.

So the fix quite possibly only papers over the problem in general
- it changes to use a new, non-cached variant in this place but I see
many more callers to gfc_get_dtype.  Eventually they will be all for
different types but who knows.

I suggest to remove the caching from gfc_get_dtype.

[Bug fortran/84155] [8 Regression] program hangs on valid code

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #17 from Paul Thomas  ---
Fixed on trunk. Thanks for the report.

Thanks, Thomas, for your help too.

Paul

[Bug fortran/84155] [8 Regression] program hangs on valid code

[tkoenig at gcc dot gnu.org]

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

--- Comment #16 from Thomas Koenig  ---
The statements are removed upon conversion to gimple:

--- Falsch/a.f90.004t.gimple2018-02-03 15:08:29.370147886 +0100
+++ Korrekt/a.f90.004t.gimple   2018-02-03 15:07:16.428178637 +0100
@@ -893,6 +893,9 @@
 [a.f90:24:0] _22 = [a.f90:24:0] [a.f90:24:0]
container.array.offset;
 [a.f90:24:0] _23 = _22 + 1;
 [a.f90:24:0] [a.f90:24:0] [a.f90:24:0] [a.f90:24:0]
[a.f90:24:0] MEM[(struct array_t[0:] *)_21][_23].child.dtype = {};
+[a.f90:24:0] [a.f90:24:0] [a.f90:24:0] [a.f90:24:0]
[a.f90:24:0] MEM[(struct array_t[0:] *)_21][_23].child.dtype.elem_len = 4;
+[a.f90:24:0] [a.f90:24:0] [a.f90:24:0] [a.f90:24:0]
[a.f90:24:0] MEM[(struct array_t[0:] *)_21][_23].child.dtype.rank = 1;
+[a.f90:24:0] [a.f90:24:0] [a.f90:24:0] [a.f90:24:0]
[a.f90:24:0] MEM[(struct array_t[0:] *)_21][_23].child.dtype.type = 1;
 [a.f90:24:0] overflow.22 = 0;
 [a.f90:24:0] if (overflow.22 != 0) goto ; else goto
;
 :
--- Falsch/a.f90.006t.omplower  2018-02-03 15:08:29.370147886 +0100
+++ Korrekt/a.f90.006t.omplower 2018-02-03 15:07:16.428178637 +0100
@@ -914,6 +914,9 @@
 [a.f90:24:0] _22 = [a.f90:24:0] [a.f90:24:0]
container.array.offset;
 [a.f90:24:0] _23 = _22 + 1;
 [a.f90:24:0] [a.f90:24:0] [a.f90:24:0] [a.f90:24:0]
[a.f90:24:0] MEM[(struct array_t[0:] *)_21][_23].child.dtype = {};
+[a.f90:24:0] [a.f90:24:0] [a.f90:24:0] [a.f90:24:0]
[a.f90:24:0] MEM[(struct array_t[0:] *)_21][_23].child.dtype.elem_len = 4;
+[a.f90:24:0] [a.f90:24:0] [a.f90:24:0] [a.f90:24:0]
[a.f90:24:0] MEM[(struct array_t[0:] *)_21][_23].child.dtype.rank = 1;
+[a.f90:24:0] [a.f90:24:0] [a.f90:24:0] [a.f90:24:0]
[a.f90:24:0] MEM[(struct array_t[0:] *)_21][_23].child.dtype.type = 1;
 [a.f90:24:0] overflow.22 = 0;
 [a.f90:24:0] if (overflow.22 != 0) goto ; else goto
;
 :

Looks like a middle-end bug to me.

[Bug fortran/84155] [8 Regression] program hangs on valid code

[pault at gcc dot gnu.org]

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

--- Comment #15 from Paul Thomas  ---
Author: pault
Date: Sat Feb  3 14:06:44 2018
New Revision: 257356

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

PR fortran/84141
PR fortran/84155
* trans-array.c (gfc_array_init_size): Instead of gfc_get_dtype
use gfc_get_dtype_rank_type.

2018-02-03  Paul Thomas  

PR fortran/84141
PR fortran/84155
* gfortran.dg/pr84155.f90 : New test.


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

[Bug fortran/84155] [8 Regression] program hangs on valid code

[paul.richard.thomas at gmail dot com]

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

--- Comment #14 from paul.richard.thomas at gmail dot com  ---
Hi Dominique,

Thanks for doing that. It was to have been my final step in the process.

I will commit the patch and then will go back to diagnose why an
unchanged tree dump yields different assembler.

Cheers

Paul


On 3 February 2018 at 12:44, dominiq at lps dot ens.fr
 wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84155
>
> --- Comment #13 from Dominique d'Humieres  ---
>> There is an important caveat to this fix, which has me very worried:
>> On top of removal of uncalled code making the bug disappear, I cannot
>> see any difference in the tree dump between the working testcase and
>> the failing version.
>
> Confirmed. However looking to the assembly for the first test, I see
>
> ...
> movq$4, (%rcx)  #, MEM[(struct array_t[0:]
> *)_21][_23].child.dtype.elem_len
> ...
> movb$1, (%rcx)  #, MEM[(struct array_t[0:]
> *)_21][_23].child.dtype.rank
> ...
> movb$1, (%rax)  #, MEM[(struct array_t[0:]
> *)_21][_23].child.dtype.type
> ...
>
> for the working case that are not present without the patch.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
> You are the assignee for the bug.

[Bug fortran/84155] [8 Regression] program hangs on valid code

[dominiq at lps dot ens.fr]

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

--- Comment #13 from Dominique d'Humieres  ---
> There is an important caveat to this fix, which has me very worried:
> On top of removal of uncalled code making the bug disappear, I cannot
> see any difference in the tree dump between the working testcase and
> the failing version.

Confirmed. However looking to the assembly for the first test, I see

...
movq$4, (%rcx)  #, MEM[(struct array_t[0:]
*)_21][_23].child.dtype.elem_len
...
movb$1, (%rcx)  #, MEM[(struct array_t[0:]
*)_21][_23].child.dtype.rank
...
movb$1, (%rax)  #, MEM[(struct array_t[0:]
*)_21][_23].child.dtype.type
...

for the working case that are not present without the patch.

[Bug fortran/84155] [8 Regression] program hangs on valid code

[tkoenig at gcc dot gnu.org]

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

--- Comment #12 from Thomas Koenig  ---
(In reply to Jürgen Reuter from comment #11)
> There was another test case that I submitted for #84141. It still failed
> after the first preliminary fix.

This one also works with the patch from comment #8 (and without
the trans-io.c patch).

Looking very good, I think.

[Bug fortran/84155] [8 Regression] program hangs on valid code

[juergen.reuter at desy dot de]

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

--- Comment #11 from Jürgen Reuter  ---
There was another test case that I submitted for #84141. It still failed after
the first preliminary fix.

[Bug fortran/84155] [8 Regression] program hangs on valid code

[pault at gcc dot gnu.org]

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

--- Comment #10 from Paul Thomas  ---
Created attachment 43328
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43328=edit
Patch for the bug

This patch fixes the PR and PR84141. The dejagnuified version of the reproducer
will appear with submission to the list - it reads back the scratch file and
checks that the value recorded is correct.

There is an important caveat to this fix, which has me very worried: On top of
removal of uncalled code making the bug disappear, I cannot see any difference
in the tree dump between the working testcase and the failing version.

I am going to have to call in the cavalry tomorrow.

Paul

[Bug fortran/84155] [8 Regression] program hangs on valid code

[juergen.reuter at desy dot de]

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

--- Comment #9 from Jürgen Reuter  ---
This fixes almost all of our unit and functional test, but not all of them.
There are still 19 functional tests failing, all of them seem to have to do
with some sort of I/O . And one unit tests, which I cannot see what it directly
does. For the latter I could do a reproducer, however, but it might take me a
day or two.

[Bug fortran/84155] [8 Regression] program hangs on valid code

[pault at gcc dot gnu.org]

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

--- Comment #8 from Paul Thomas  ---
A temporary fix:

Index: ../trunk/gcc/fortran/trans-io.c
===
*** ../trunk/gcc/fortran/trans-io.c (revision 257261)
--- ../trunk/gcc/fortran/trans-io.c (working copy)
*** gfc_trans_transfer (gfc_code * code)
*** 2590,2596 

if (expr->ts.type != BT_CLASS
 && expr->expr_type == EXPR_VARIABLE
!&& gfc_expr_attr (expr).pointer)
goto scalarize;


--- 2590,2596 

if (expr->ts.type != BT_CLASS
 && expr->expr_type == EXPR_VARIABLE
!&& (gfc_expr_attr (expr).pointer || gfc_expr_attr (expr).allocatable))
goto scalarize;

fixes this and pr84141.

transfer_array is receiving a dtype with all the fields set to zero. I will get
back to this tonight or tomorrow morning. I have to go to the lab now.

Paul

[Bug fortran/84155] [8 Regression] program hangs on valid code

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #7 from Paul Thomas  ---
Stranger and stranger. Not only does the removal of a line in a subroutine that
is not called make the testcase work but explicitly using the subroutine to do
the allocation works as well:

module test_case

  implicit none

  type :: array_t
 integer, dimension(:), allocatable :: child
   contains
 procedure :: write_raw => particle_write_raw
 procedure :: read_raw => particle_read_raw
  end type array_t

  type :: container_t
 type(array_t), dimension(:), allocatable :: array
  end type container_t

contains

  subroutine proc ()
type(container_t) :: container
integer :: unit, child

allocate (container%array(1))
!allocate (container%array(1)%child (1), source = [2])
call container%array(1)%read_raw ()

unit = 33
open (unit, action="readwrite", form="unformatted", status="scratch")
print *, 1
call container%array(1)%write_raw (unit)
print *, 2
rewind (unit)
read(unit) child
print *, "value from scratch file = ", child
  end subroutine proc

  subroutine particle_write_raw (array, u)
class(array_t), intent(in) :: array
integer, intent(in) :: u
write (u) array%child
  end subroutine particle_write_raw

  subroutine particle_read_raw (array)
class(array_t), intent(out) :: array
allocate (array%child (1), source = [99])! comment this out
  end subroutine particle_read_raw

end module test_case

program main
  use test_case
  call proc ()
  end program main

I have taken it, although I might need help from you Thomas since I rather
suspect something is bad in the i/o library.

Paul

[Bug fortran/84155] [8 Regression] program hangs on valid code

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Keywords||wrong-code
   Priority|P3  |P4
Summary|[8.0 Regression] program|[8 Regression] program
   |hangs on valid code |hangs on valid code

--- Comment #6 from Dominique d'Humieres  ---
This PR is not fixed by r257262.