[Bug fortran/70856] [6/7 Regression] ICE with -fopenacc in get_constraint_for_ssa_var, at tree-ssa-structalias.c:2952

[rguenther at suse dot de]

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

--- Comment #8 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 17 May 2016, marxin at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70856
> 
> Martin Liška <marxin at gcc dot gnu.org> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |marxin at gcc dot gnu.org
> 
> --- Comment #7 from Martin Liška <marxin at gcc dot gnu.org> ---
> (In reply to Richard Biener from comment #6)
> > (In reply to vries from comment #5)
> > > before icf, we have:
> > > ...
> > >   static real(kind=4) A.4[2] = {1.0e+0, 2.0e+0};
> > >   static real(kind=4) A.1[2] = {1.0e+0, 2.0e+0};
> > > ...
> > > 
> > > Then icf does:
> > > ...
> > > Semantic equality hit:A.4->A.1
> > > Assembler symbol names:A.4.3435->A.1.3429
> > > Unified; Variable alias has been created.
> > > ...
> > > 
> > > And after icf, we have:
> > > ...
> > >   static real(kind=4) A.4[2] = {1.0e+0, 2.0e+0};
> > >   static real(kind=4) A.1[2];
> > > ...
> > > 
> > > What openacc does, is run ipa-pta before and after icf.
> > > 
> > > The compilation succeeds with -fno-ipa-icf.
> > 
> > Hmm, indeed running ICF after IPA PTA invalidates points-to info (eventually
> > even causing wrong-code).  There is nothing ICF can do here (it would need
> > to adjust all points-to bitmaps).
> > 
> > Note that this is true also for non-IPA PTA info.
> > 
> > The wrong-code possibilities (given that we only merge readonly decls in ICF)
> > restrict themselves to equality/inequality compares which constitute an area
> > in ICF that is fishy anyway.
> > 
> > That said - if ICF would adjust DECL_PT_UID then a testcase like
> > 
> > static const int a[] = { 1, 2, 3, 4 };
> > static const int b[] = { 1, 2, 3, 4 };
> > 
> > bool isA (int *p) { return p == a; }
> > bool isB (int *p) { return p == b; }
> > int main()
> > {
> >   if (! (isA (a) || isB (a)))
> >     abort (); 
> > }
> 
> In the following sample, we do not merge because of:
> "Not unifying; adress of original and alias may be compared."
> 
> > 
> > could start to abort (it's a bit tricky and would involve some disabling
> > of some CCP I guess).
> > 
> > Honza, Martin - I suppose if we start to comare DECL_PT_UID in ICF then
> > this effectively disables ICF of variables.  Any ideas besides adjusting
> > DECL_PT_UID in ICF and hoping for the best (on the wrong-code issue)?
> 
> I would expect that we'll kill majority of merges of variables.
> Well, using the obvious patch:
> 
> diff --git a/gcc/ipa-icf.c b/gcc/ipa-icf.c
> index dda5cac..3c04b5a 100644
> --- a/gcc/ipa-icf.c
> +++ b/gcc/ipa-icf.c
> @@ -2258,6 +2258,8 @@ sem_variable::merge (sem_item *alias_item)
> 
>        varpool_node::create_alias (alias_var->decl, decl);
>        alias->resolve_alias (original);
> +      if (DECL_PT_UID_SET_P (original->decl))
> +       SET_DECL_PT_UID (alias->decl, DECL_PT_UID (original->decl));
> 
>        if (dump_file)
>         fprintf (dump_file, "Unified; Variable alias has been created.\n\n");
> 
> The ICE has gone. However, I can't imagine if it can have any negative
> consequences?

If ICF made sure the decls didn't have their address taken it doesn't
have any negative consequence.

Richard.