On Tue, Apr 12, 2016 at 05:49:26PM +0200, Richard Biener wrote:
> On April 12, 2016 4:54:27 PM GMT+02:00, Jakub Jelinek <[email protected]>
> wrote:
> >Hi!
> >
> >Even without the C++ FE changes, I believe there are occassional
> >DECL_UID
> >differences (I believe the code just cares that the ordering of the
> >uids
> >is stable), and the fancy DEC_IGNORED names can leak into the
> >-fdump-final-insns= dumps (e.g. in MEM_EXPRs or REG_EXPRs.
> >
> >The following patch treats those similarly to how the various TDF_NOUID
> >flags handle it in the dumps.
> >
> >Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> >
> >2016-04-12 Jakub Jelinek <[email protected]>
> >
> > PR c++/70594
> > * tree-sra.c (make_fancy_decl_name): Don't add DECL_UID
> > into the fancy names if -fdump-final-insns=.
> >
> >--- gcc/tree-sra.c.jj 2016-04-12 11:08:10.000000000 +0200
> >+++ gcc/tree-sra.c 2016-04-12 11:15:35.519676357 +0200
> >@@ -1543,6 +1543,9 @@ make_fancy_decl_name (tree decl)
> > if (name)
> > obstack_grow (&name_obstack, IDENTIFIER_POINTER (name),
> > IDENTIFIER_LENGTH (name));
> >+ /* Avoid -fcompare-debug issues on DECL_UID differences. */
> >+ else if (flag_dump_final_insns != NULL)
> >+ obstack_grow (&name_obstack, "Dxxxx", 5);
> > else
> > {
> > sprintf (buffer, "D%u", DECL_UID (decl));
>
> I'd rather use a separate counter that SRA increments. We an always dump
> counter to uid mapping.
So you mean add another hash table that maps DECL_UIDs to these SRA
counters? Because if we dump there any number of say FIELD_DECL, it would
be desirable to use the same number on any further fancy names with that
FIELD_DECL.
Do it unconditionally, or just for flag_dump_final_insns?
Jakub
