On Tue, Sep 6, 2016 at 10:43 AM, Pierre-Marie de Rodat
<dero...@adacore.com> wrote:
> Hello,
>
> On 08/29/2016 11:03 AM, Pierre-Marie de Rodat wrote:
>>
>> Here is another attempt to solve the original issue. This time, with a
>> proper testcase. ;-)
>>
>> Rebased against trunk, boostrapped and regtested on x86_64-linux.
>
>
> Ping for the patch submitted at
> <https://gcc.gnu.org/ml/gcc-patches/2016-08/msg01934.html>. Thank you in
> advance!

Ok, had time to look at this issue again.  I see the patch works like dwarf2out
works currently with respect to DIE creation order and re-location.

-       /* Output a DIE to represent the typedef itself.  */
-       gen_typedef_die (decl, context_die);
+       {
+         /* Output a DIE to represent the typedef itself.  */
+         gen_typedef_die (decl, context_die);
+
+         /* The above may create a typedef in the proper scope, but the
+            underlying type itself could have been created earlier, at a point
+            when the scope was not available yet.  If it's the case, relocate
+            it.  This is analogous to what is done in process_scope_var,
+            except we deal with a TYPE and not a DECL, here.  */
+         dw_die_ref type_die = lookup_type_die (TREE_TYPE (decl));
+         if (type_die != NULL && type_die->die_parent == NULL
+             && DECL_CONTEXT (decl) == TYPE_CONTEXT (TREE_TYPE (decl)))
+           add_child_die (context_die, type_die);
+       }

this might be incomplete though for the case where it's say

 typedef const T X;

thus the type of decl is a qualified type?  In this case the qualification might
be at the correct scope but the actual type not or you just relocate the
qualification but not the type DIE it refers to?

That said, with the idea of early debug in place and thus giving more
responsibility
to the frontends I wonder in what order the Ada FE calls
debug_hooks.early_global_decl ()?
Maybe it's the middle-end and it should arrange for a more natural
order on function
nests.  So I'd appreciate if you can investigate this side of the
issue a bit, that is, simply
avoid the bad ordering.

Richard.

> --
> Pierre-Marie de Rodat

Reply via email to