https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65549
--- Comment #30 from rguenther at suse dot de <rguenther at suse dot de> --- On Fri, 17 Apr 2015, jason at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65549 > > Jason Merrill <jason at gcc dot gnu.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |jason at gcc dot gnu.org > > --- Comment #29 from Jason Merrill <jason at gcc dot gnu.org> --- > (In reply to Jakub Jelinek from comment #17) > > Lambda functions aren't really nested functions in the tree-nested.c sense, > > but still are so closely related to the functions they are nested in that > > IMHO it would be desirable not to split them off into separate partitions, > > not just temporarily for GCC 5 for debug info reasons. > > Agreed. decl_function_context of the lambda function should give you the > containing function. As far as I understood imposing constraints like this to the partitioner is hard because either you implement the same constraints into the inliner as well or you eventually blow up partition sizes. I'm also not 100% sure the issue we hit in dwarf2out is specific to lambdas or nested functions - it might very well trigger with regular C++ classes as well, just harder to reproduce. So at least for branches I think my patch is the way to go - eventually guarded with in_lto_p (if you really insist on that...)
