Re: Fwd: [Patch, fortran] PR60717 - Wrong code with recursive procedure with unlimited polymorphic dummy argument

[Paul Richard Thomas <paul dot richard dot thomas at gmail dot com>]

Dear All,

I have upgraded this patch slightly to fix PR58085 as well. I would
judge this to be completely safe because the fixes depend on the new
bit flag for both PRs.

Bootstrapped and regtested on FC17/x86_64 - OK for 4.9 immediately and trunk?

Paul

2014-04-12  Paul Thomas  <pault@gcc.gnu.org>

    PR fortran/60717
    PR fortran/58085
   * trans.h: Add 'use_offset' bitfield to gfc_se.
    * trans-array.c (gfc_conv_expr_descriptor): Use 'use_offset'
    as a trigger to unconditionally recalculate the offset for
    array slices and constant arrays.
    trans-expr.c (gfc_conv_intrinsic_to_class): Use it.
    trans-stmt.c (trans_associate_var): Ditto.
    (gfc_conv_procedure_call): Ditto.

2014-04-12  Paul Thomas  <pault@gcc.gnu.org>

    PR fortran/60717
    * gfortran.dg/unlimited_polymorphic_17.f90: New test.

    PR fortran/58085
    * gfortran.dg/associate_15.f90: New test.

On 12 April 2014 10:30, Jakub Jelinek <jakub@redhat.com> wrote:
> On Sat, Apr 12, 2014 at 07:27:00AM +0200, Paul Richard Thomas wrote:
>> I know that you are probably snowed under with requests like this!  I
>> was away on a business trip when Mikael's approval below came and had
>> intended to apply it to 4.9 aka trunk today. Is it OK with you if I
>> slip it into 4.9 or should I let it go until after the release?
>
> I'd prefer to put it in after the release, especially for non-regressions
> or regressions that aren't regressions from 4.8.2.
> 4.9.1 will be probably 2 months away from 4.9.0, and many people use release
> branch snapshots anyway, but I'd prefer to avoid any risks of slipping the
> release further.
>
>         Jakub



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

Attachment: pr60717_58085.diff
Description: Text document