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