[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 <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |---

--- Comment #18 from Richard Biener <rguenth at gcc dot gnu.org> ---
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 *) &A.20[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.