On February 8, 2014 5:08:52 PM GMT+01:00, Paul Richard Thomas <paul.richard.tho...@gmail.com> wrote: >Dear All, > >I am aware that we are in stage 4 but this wrong-code-on-valid PR is >confined to a corner of a corner and so I am certain that it can be >safely applied - OK, Richie?
Ok with me. Richard. >This patch follows the same route as has been used for pointer array >assignment to components of derived type arrays by rolling out the >auxilliary 'span' variable for the associate-name to give it the >correct extent. Once the array descriptor reform has been completed, >this fix should be removed. All such code can be found by grepping on >'subref_array', so the excision will be swift and painless :-) > >Note that this is not needed for SELECT_TYPE since it is inaccessible >there: "component to the right of an array reference may not have >ALLOCATABLE or POINTER attribute" && "class component must be >ALLOCATABLE or POINTER" = false for any selector that I have been able >to construct. > >Bootstraps and regtests on FC17/x86_64 - OK for trunk and 4.8? > >Cheers > >Paul > >2014-02-08 Paul Thomas <pa...@gcc.gnu.org> > > PR fortran/57522 > * resolve.c (resolve_assoc_var): Set the subref_array_pointer > attribute for the 'associate-name' if necessary. > * trans-stmt.c (trans_associate_var): If the 'associate-name' > is a subref_array_pointer, assign the element size of the > associate variable to 'span'. > >2014-02-08 Paul Thomas <pa...@gcc.gnu.org> > > PR fortran/57522 > * gfortran.dg/associated_target_5.f03 : New test
