[Patch, Fortran] PR41629: [OOP] gimplification error on valid code

[Paul Richard Thomas]

Janus,

I promptly went off on another and about to do so again.  This time,
however, I have put your patch on a memory stick!  I'll do it at the
airport...

Cheers

Paul

On Sat, Oct 10, 2009 at 11:08 PM, Janus Weil <janus@gcc.gnu.org> wrote:
> Paul,
>
>> I'll look at this patch tomorrow.  I just got back from a trip.
>
> thanks, that would be great. But if you do so, please don't look at
> the patch I sent before, but at the update I'm attaching here.
>
> In the previous version, I moved the call to
> 'encapsulate_class_symbol' to resolution stage only for plain CLASS
> variables, but not for CLASS-valued components. I think it's better
> (necessary?) to also do this for components. Note: For components the
> attributes are known when parsing the component declaration (which is
> just one line), but the type of the component does not have to be
> previously defined. Also it's just cleaner to do the encapsulation at
> the same point (namely: resolution stage) for *all* CLASS entities
> (including components). So I moved 'encapsulate_class_symbol' to
> resolve.c and made it static again.
>
> As an aside, I also had to fix an error in gfc_match_allocate: There,
> gfc_resolve_expr was called for the SOURCE tag, but of course
> resolving should only happen at resolution stage, and not yet when
> parsing. Consequently, some error checks (including the function
> 'conformable_arrays') had to be moved to resolve_allocate_expr, since
> they rely on the SOURCE expression being resolved.
>
> I think the patch is regression-free (will re-check). Of course I will
> also update the ChangeLog.
>
> Ok for trunk?
>
> Cheers,
> Janus
>



-- 
The knack of flying is learning how to throw yourself at the ground and miss.
       --Hitchhikers Guide to the Galaxy