[PATCH] Fix PR85020

[Jakub Jelinek]

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