Hi Paul, > As part of Tobias's fix for PR50640, he introduced: > > + if ((sym->attr.flavor == FL_PARAMETER > + && (sym->attr.dimension || sym->ts.type == BT_DERIVED)) > + || sym->attr.vtab) > TREE_READONLY (decl) = 1; > > Is this not sufficient to fix this PR too?
well, I think what you quote here is a proposed patch which was not committed. What Tobias actually committed for PR50960 is this: http://gcc.gnu.org/viewcvs/trunk/gcc/fortran/trans-decl.c?r1=180878&r2=180877&pathrev=180878 It does not contain any special case for vtabs (which is not needed if the vtabs become parameters). To answer your question: With respect to TREE_READONLY Tobias' patch is surely equivalent. I was hoping that FL_PARAMETER might have other (positive) side effects, but I'm not sure about that. If you think it's preferable, I can commit Tobias' version instead ... Cheers, Janus > On Tue, Nov 8, 2011 at 11:51 AM, Janus Weil <ja...@gcc.gnu.org> wrote: >> Hi all, >> >> the attached patch marks the 'vtab' symbols as constant >> (FL_PARAMETER). They are fixed objects which are initialized once and >> never change. >> >> Regtested on x86_64-unknown-linux-gnu. Ok for trunk? >> >> Is it ok to commit without a test case? If not, any suggestions how a >> good test case could look like? >> >> Cheers, >> Janus >> >> >> 2011-11-08 Janus Weil <ja...@gcc.gnu.org> >> >> PR fortran/50960 >> * class.c (gfc_find_derived_vtab): Make the vtab symbols FL_PARAMETER. >> * expr.c (gfc_simplify_expr): Prevent vtabs from being replaced with >> their value. >> * resolve.c (resolve_values): Use-associated symbols do not need to >> be resolved again. >> (resolve_fl_parameter): Make sure the symbol has a value. >> > > > > -- > The knack of flying is learning how to throw yourself at the ground and miss. > --Hitchhikers Guide to the Galaxy >
