> 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
