On Sat, Feb 04, 2023 at 06:02:46PM -0800, Jason Merrill via Gcc-patches wrote:
> On 2/4/23 20:41, Jason Merrill wrote:
> > On 2/4/23 20:08, Patrick Palka wrote:
> > > On Sat, 4 Feb 2023, Jason Merrill wrote:
> > > > > diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
> > > > > index 255332dc0c1..c9360240cd2 100644
> > > > > --- a/gcc/cp/pt.cc
> > > > > +++ b/gcc/cp/pt.cc
> > > > > @@ -1841,6 +1841,7 @@ iterative_hash_template_arg (tree arg,
> > > > > hashval_t val)
> > > > > case CALL_EXPR:
> > > > > {
> > > > > tree fn = CALL_EXPR_FN (arg);
> > > > > + if (TREE_TYPE (arg) == NULL_TREE)
> > > >
> > > > How about changing dependent_name to take the CALL_EXPR rather than the
> > > > CALL_EXPR_FN? That would mean some changes to write_expression
> > > > to move the
> > > > dependent_name handling into the CALL_EXPR handling, but that
> > > > doesn't seem
> > > > like a bad thing. Other callers seem like a trivial change.
> > >
> > > Indeed changing dependent_name seems best, but I'm worried about such a
> > > refactoring to write_expression causing unintended mangling changes at
> > > this stage. Because it seems the CALL_EXPR case of write_expression
> > > isn't the user of the dependent_name branch of write_expression, at
> > > least according to the following patch which causes us to ICE on
> > > mangle{37,57,58,76}.C:
> >
> > Yeah, I tried the same thing. Maybe for GCC 13 better to add a new
> > function rather than change the current one.
>
> mangle76 seems like a bug where we're producing (and testing for) the wrong
> mangling -- mangling (*this). that doesn't exist in the source. clang gets
> it right.
Yes, this is https://gcc.gnu.org/PR98756.
> mangle5{7,8} has the right mangling, we're just using dependent_name to
> mangle function names that aren't dependent names (because they're template
> arguments in both cases, and qualified in the latter).
Marek
