[Bug middle-end/89725] ICE in get_fnname_from_decl, at varasm.c:1723

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to bin cheng from comment #7)
> I am testing below simple fix, it bypass access functions doesn't belong to
> analyzing loop_nest:
> 
> diff --git a/gcc/tree-data-ref.c b/gcc/tree-data-ref.c
> index e536b463e96..410d44f43e8 100644
> --- a/gcc/tree-data-ref.c
> +++ b/gcc/tree-data-ref.c
> @@ -4272,6 +4272,7 @@ build_classic_dist_vector_1 (struct
> data_dependence_relation *ddr,
>  {
>    unsigned i;
>    lambda_vector init_v = lambda_vector_new (DDR_NB_LOOPS (ddr));
> +  struct loop *loop = DDR_LOOP_NEST (ddr)[0];
>  
>    for (i = 0; i < DDR_NUM_SUBSCRIPTS (ddr); i++)
>      {
> @@ -4302,6 +4303,15 @@ build_classic_dist_vector_1 (struct
> data_dependence_relation *ddr,
>               return false;
>             }
>  
> +         /* When data references are collected in a loop while data
> +            dependences are analyzed in loop nest nested in the loop, we
> +            would have more number of access functions than number of
> +            loops.  Skip access functions of loops not in the loop nest.
> +
> +            See PR89725 for more information.  */
> +         if (flow_loop_nested_p (get_loop (cfun, var_a), loop))
> +           continue;
> +
>           dist = int_cst_value (SUB_DISTANCE (subscript));
>           index = index_in_loop_nest (var_a, DDR_LOOP_NEST (ddr));
>           *index_carry = MIN (index, *index_carry);
> 
> Plus the assert in index_in_loop_nest.

I wondered about chrecs like { 1, +, { 0 +, 1 }_1 }_2 (inner loop step
or initial value evolves wrt outer loop).  We'd not catch that here.

Also if the above is possible then why not simply strip those
subscripts when we build the DDR?  That way the few other cases
we do index_in_loop_nest also are "fixed".

Meanwhile testing of my patch finished but shows an ICE for

FAIL: gfortran.dg/vect/pr81303.f   -O   scan-tree-dump-times linterchange "is
in
terchanged" 1
FAIL: gfortran.dg/vect/pr81303.f   -O  (internal compiler error)
FAIL: gfortran.dg/vect/pr81303.f   -O  (test for excess errors)

#1  0x0000000000a61759 in vec<tree_node*, va_heap, vl_embed>::operator[] (
    this=0x3119f50 = {...}, ix=3)
    at /space/rguenther/src/gcc-sccvn/gcc/vec.h:845
845       gcc_checking_assert (ix < m_vecpfx.m_num);
(gdb) 
#3  0x0000000001f2723a in should_interchange_loops (i_idx=3, o_idx=2, 
    datarefs=..., i_stmt_cost=41, o_stmt_cost=5, innermost_loops_p=true, 
    dump_info_p=true)
    at /space/rguenther/src/gcc-sccvn/gcc/gimple-loop-interchange.cc:1460
1460          tree iloop_stride = (*stride)[i_idx], oloop_stride =
(*stride)[o_idx];

where the interchange code would need further changes for my change of the
loop-nest for DDRs.

That said, can we strip subscripts for outer loops in
initialize_data_dependence_relation when we compute them?
OTOH the cases where we can ignore the subscript are not so clear
given that the outer loop behavior can very well compute
non-aliasing.  So selectively pruning just the unwanted distance
vectors looks safe.

But what about similar code in add_multivariate_self_dist or
add_other_self_distances?