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
>

Reply via email to