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

[amker at gcc dot gnu.org]

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

--- Comment #9 from bin cheng <amker at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #8)
> (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
Agree there may be more opportunities to disambiguate dependence with more
SCEVed access function of outer loop. 

> non-aliasing.  So selectively pruning just the unwanted distance
> vectors looks safe.
As you mentioned, multivariate needs to be handled with outer loop SCEV handled
as some kind of invariant.  This is necessary no matter we bypass it in dist
vector construction or DDR initialization/computation.  As you suggested, we
can't undo it yet...

> 
> But what about similar code in add_multivariate_self_dist or
> add_other_self_distances?