https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68860
--- Comment #7 from rguenther at suse dot de <rguenther at suse dot de> --- On Tue, 22 Dec 2015, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68860 > > --- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> --- > (In reply to Jakub Jelinek from comment #4) > > Created attachment 37097 [details] > > gcc6-pr68860-lto.patch > > > > I've noticed that the new tests still fail with LTO. > > It seems the reason is that LTO ignores DECL_HAS_DEBUG_ARGS_P etc., so this > > stuff is just lost. > > I've added some changes so that this is streamed, but it seems that is not > > enough, DECL_ORIGIN of the decls is wrong, so it isn't used anyway. > > BTW, Honza, why is: > > if (code == VAR_DECL > > && DECL_HAS_DEBUG_EXPR_P (t)) > > visit (DECL_DEBUG_EXPR (t)); > > used in hash_tree? Depends on what the function is used for, if it is for > > code generation or something like that, better it should not depend on the > > debug info stuff... > > So, the reason why nothing is emitted on the callee side with this patch is > that LTO does never stream DECL_ABSTRACT_ORIGIN, and this is used to double > check the data before actually trying to emit anything. Perhaps this could be > bypassed by some lto condition, but in any case we'd need a way how to find > out > the correspondence between those decl_debug_args decls and the original > arguments that were optimized away. > The reason why nothing is emitted on the caller sides is that for some reason > when streaming in the decl_debug_args, all the DEBUG_EXPR_DECLs turn out to be > D#1, while they really should be D#1, D#2 etc. and the DEBUG_EXPR_DECLs > emitted > in the callers before those calls should match them, while they are assigned > independently. I wouldn't worry about this too much (LTO) for GCC 6 but you can experiment with just letting the specific case through streaming (and otherwise stream NULL_TREE). early LTO debug is supposed to fix all this ...
