On Thu, Mar 22, 2018 at 03:16:22PM +0100, Richard Biener wrote: > the upper bound decl is global as well). Jakub, do you remember > a reason for having any constraints here? I've reworked the
I don't, but it has been added in the https://gcc.gnu.org/ml/gcc-patches/2017-02/msg01499.html patch. It matches what we were using before: - if (loc == NULL - && early_dwarf - && current_function_decl - && DECL_CONTEXT (rszdecl) == current_function_decl) when emitting the DW_OP_call4 stuff. But more importantly, it seems that resolve_variable_value_in_expr will not change anything if tree decl = loc->dw_loc_oprnd1.v.val_decl_ref; if (DECL_CONTEXT (decl) != current_function_decl) continue; Which means resolve_variable_values would never process those DW_OP_GNU_variable_value you've added, and I believe later on note_variable_value_in_expr will just ICE on it: if (loc->dw_loc_opc == DW_OP_GNU_variable_value && loc->dw_loc_oprnd1.val_class == dw_val_class_decl_ref) ... if (! ref && (flag_generate_lto || flag_generate_offload)) { /* ??? This is somewhat a hack because we do not create DIEs for variables not in BLOCK trees early but when generating early LTO output we need the dw_val_class_decl_ref to be fully resolved. For fat LTO objects we'd also like to undo this after LTO dwarf output. */ gcc_assert (DECL_CONTEXT (decl)); Because DECL_CONTEXT (decl) is NULL, right? Or is DECL_CONTEXT never NULL in LTO, just TRANSLATION_UNIT_DECL? If so, perhaps note_variable_value_in_expr will handle those fine, but for these we really don't want to force any DIEs, but rather just give up if lookup_decl fails by the time we've processed the whole TU. Jakub
