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.
