I've submitted bug 81135 to track this - https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81135 On Tue, Jun 20, 2017 at 8:27 AM, Richard Biener <richard.guenther@xxxxxxxxx> wrote: > On Mon, Jun 19, 2017 at 7:18 PM, Jason Merrill <jason@xxxxxxxxxx> wrote: >> On Mon, Jun 19, 2017 at 3:45 AM, Richard Biener >> <richard.guenther@xxxxxxxxx> wrote: >>> On Sat, Jun 17, 2017 at 9:09 AM, Siva Narayanan <sinaraya@xxxxxxxxxx> wrote: >>>> Hello all, >>>> >>>> My colleague Peter managed to use "git bisect" on the git mirror of >>>> gcc source code. The commit from a branch called "debug-early" seems >>>> like a possible point when the new behavior got introduced. >>>> >>>> We have also looked at this conversation: >>>> https://gcc.gnu.org/ml/gcc/2015-05/msg00046.html >>>> >>>> We would like to know if this work: >>>> >>>>>Shortly after the merge I'll work on a pass to prune unused decl DIEs as >we're presently creating more DIEs than mainline. This was expected, >and if I understood Jason correctly, it is ok to work on this post-merge. >However, even without such a pass, the .debug_info size difference is >reasonable: >>>> >>>> happened along with a future commit or if there is still some work >>>> pending. As I wrote, in our environment the debug_info size difference >>>> (from earlier 5.4 version of gcc) is significant that the object file >>>> size change is non-trivial with gcc 6.3.1. >>> >>> To my knowledge this hasn't happened yet. >> >> Is there an open PR for this? > > I can't find one but IIRC there was one maybe only slightly related to > this and thus already "fixed". In talking to > Pierre-Marie about some dwarf2 patch he has to not bail out early when > trying to emit early debug for > declarations (w/o struct function) I also mentioned the possibility of > always generating those DIEs but later > doing sth like the unused type DIE removal for (global) decl DIEs as > well (just do a symtab lookup at early finish > time and see if there are any references to it, if not, prune the DIE). > > Deciding on if sth is used at the point we call > dwarf2out_early_global_decl seems premature given that > is called by rest_of_decl_compilation which the FEs call happily > during parsing already. > > Richard. > >> Jason
