https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93339
Tobias Burnus <burnus at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |burnus at gcc dot gnu.org
--- Comment #4 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Created attachment 48243
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48243&action=edit
Extended test case
I have tried with GCC 7 ā while some variants to not crash, others do and it
also does not work at run time. The full test case shows the same compile-time
error as trunk (see last item in this comment). Hence, it is not a "real"
regression.
* * *
The problem is at
associate (y => x%a)
here,
expr = "x%a"
but
expr->ts.u.cl->backend_decl == ".z".
When processing "associate (y => x%a)", gfc_get_array_span() gets the
descriptor (desc) and the "expr" from above as input. (When called from
trans_associate_var.)
Thus, one ends up with:
integer(kind=8) .y;
struct array01_unknown y;
y = x.a;
y.span = .z; // should be .y instead (+ at some point initialized)
If one uses "y => x%a(:)(1:3)", one gets:
.z = 3
Hence, .z is no longer uninitialized. Still, '.z' is not defined in this scope
ā which causes the ICE.
If one only has only one ASSOCIATE, this works has there is only a '.y'.
In the attached test case (when commenting the two inner associate):
'y = x%a(:)(1:3)' works
but 'y2 => x%a' fails at the run-time check as 'y == ['AB','CD'] instead of
['ABC','DEF'] (why?)
* * *
Additionally, there are odd errors for the inner associate, which does not show
up for the outer associate; it might be well related to the expr->ts.u.cl
issue, but could also be an issue of its own.
associate (z => x%a(:)(1:2))
1
Error: Substring end index at (1) exceeds the string length
foo3.f90:18:31:
associate (z => x%a(:)(1:2))
1
Error: Entity āzā at (1) has a deferred type parameter and requires either the
POINTER or ALLOCATABLE attribute
