Hi,

Switching mailinglist from gcc to gdb.

On Mon, 2017-03-13 at 18:54 +0000, Pedro Alves wrote:
> On 03/13/2017 06:29 PM, Mark Wielaard wrote:
> 
> > O, sorry. I should have let Nick known about the gdb regressions I found.
> > Besides this patch gdb needs the following one-liner fix:
> > 
> > diff --git a/gdb/cp-name-parser.y b/gdb/cp-name-parser.y
> > index fd1e949..5278c05 100644
> > --- a/gdb/cp-name-parser.y
> > +++ b/gdb/cp-name-parser.y
> > @@ -201,6 +201,7 @@ make_empty (enum demangle_component_type d_type)
> >  {
> >    struct demangle_component *ret = d_grab ();
> >    ret->type = d_type;
> > +  ret->d_printing = 0;
> >    return ret;
> >  }
> 
> Should gdb be memsetting instead to avoid having to know about
> libiberty's "internals"?

Maybe. But I went with the version I tested.

Basically none of this would be needed if gdb only used the
cplus_demangle_fill_* functions to initialize the data structures
(although that is where there was a bug, but that is now fixed).

cp-name-parser.y however sometimes uses the cplus_demangle_fill
functions, but other times fills in the data structures by hand (using
its own partial fill function make_empty). I know too little of this
code to know why. Maybe the set of cplus_demangle_fill functions isn't
complete enough or maybe the way the parser works not all information
needed is there yet to call cplus_demangle_fill or maybe doing it by
hand just felt more efficient?

>  Either version is pre-approved for GDB.

Thanks. I checked in the attached to merge libiberty again and fix
cp-name-parser.y make_empty.

Cheers,

Mark