[patch 10/10] debug-early merge: compiler proper

Jan Hubicka hubicka@ucw.cz
Thu May 28 21:01:00 GMT 2015


> On 05/28/2015 02:53 PM, Aldy Hernandez wrote:
> >On 05/27/2015 08:39 AM, Jason Merrill wrote:
> >>On 05/20/2015 11:50 AM, Aldy Hernandez wrote:
> >
> >>>+  /* Fill in the size of variable-length fields in late dwarf.  */
> >>>+  if (TREE_ASM_WRITTEN (type)
> >>>+      && !early_dwarf_dumping)
> >>>+    {
> >>>+      tree member;
> >>>+      for (member = TYPE_FIELDS (type); member; member = DECL_CHAIN
> >>>(member))
> >>>+    fill_variable_array_bounds (TREE_TYPE (member));
> >>>+      return;
> >>>+    }
> >>
> >>Why is this happening in late dwarf?  I'm concerned that front-end
> >>information that is necessary to do this might be lost by that point.
> >
> >I thought only after the optimizations had run their course would we be
> >guaranteed to have accurate bound information.  At least, that's what my
> >experience showed.
> 
> Hmm, I'm don't know why optimizations would change the
> representation of the array type.

I don't think we change representation ATM, but eventually we want to get into
the datastructure reordering busyness.  I suppose to get this debug output
friendly, we will need a way to update the existing dwarf DIE to whatever
changes we want.

As for optimization changing type representation, I suppose one case is when
function with varray type gets inlined and the array bound happens to be a
different expression afterwards.  We produce a new copy of the original type
with different bounds then.

Honza



More information about the Gcc-patches mailing list