https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71330
--- Comment #11 from Patrick Palka <ppalka at gcc dot gnu.org> --- (In reply to Patrick Palka from comment #10) > I think the problem is with cp_fold_function() which does > > cp_walk_tree (&DECL_SAVED_TREE (fndecl), cp_fold_r, NULL, NULL); > > and cp_fold_r is itself recursive so the number of calls made to cp_fold_r > via cp_fold_function() is quadratic with respect to the size of the > function's subexpressions. The test case features a huge subexpression > arising from the chain of overloaded <<s. My guess is wrong. Removing the call to cp_fold within cp_fold_r doesn't fix the slowdown. But calling cp_walk_tree instead of cp_walk_tree_without_duplicates does...