Re: [Ping, Patch, fortran, 64674, v3] [OOP] ICE in ASSOCIATE with class array

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

Hi Andre,

Some questions: The first and second chunks look a bit awkward in
parse.c. Do they have to be there in order that primary.c does the
right thing? Could the whole lot be transferred to resolve.c or would
that make it horribly messy? I couldn't apply the patch right now -
does it work with variable expressions for the target array indices?

If the answers are (i) yes (ii) no (iii) yes, then OK for trunk.

If the answer to (iii) is yes, please extend or modify the testcase to
check for variable indices.

Thanks for the patch

Paul

On 19 June 2015 at 12:58, Andre Vehreschild <vehre@gmx.de> wrote:
> Hi all,
>
> a ping on this patch. Rebased to current trunk.
>
> Bootstraps and regtests fine on x86_64-linux-gnu/f21.
>
> Ok for trunk?
>
> - Andre
>
>> On Mon, 4 May 2015 16:53:15 +0200
>> Andre Vehreschild <vehre@gmx.de> wrote:
>>
>> > Hi all,
>> >
>> > I like to present here a first patch for using class arrays in associate.
>> > Upto now gfortran crashed, when a class array-section/element was selected
>> > in an associate. This patch fixes this now for class array sections as well
>> > as for single elements.
>> >
>> > The story of the patch is told quite shortly:
>> >
>> > - parse.c::parse_associate() needs to gather more information about what the
>> >   target is like. Previously the target's rank and array_spec was not
>> > computed, which disallowed the use of further array refs in the associate
>> > body: associate (vec => class_matrix(2:3, 2))
>> >     vec(1) = ... ! <- Unclassifiable statement, because no array_spec was
>> >   attached to vec. This is fixed by the second hunk of the patch.
>> >
>> > - The third hunk in primary.c prevents setting the dimension attribute on a
>> >   class object's symbol.
>> >
>> > - The hunks in resolve.c take care about adding dummy full array_refs and in
>> >   resolve_assoc_var correct the class type, when the target expression's
>> > rank is 0. Previously the symbol would have an array valued type, when the
>> >   target's base type was array valued. But for a scalar target this needed
>> > some polishing.
>> >
>> > - Additionally a test was added.
>> >
>> > Bootstraps and regtests ok on x86_64-linux-gnu/f21.
>> >
>> > Ok for trunk?
>> >
>> > Note, this patch was diffed from a trunk with my older patches for
>> >
>> > PR65548, v3 https://gcc.gnu.org/ml/fortran/2015-04/msg00123.html and
>> > PR44672, v5 https://gcc.gnu.org/ml/fortran/2015-04/msg00124.html
>> >
>> > applied.
>> >
>> > Regards,
>> >     Andre
>>
>>
>
>
> --
> Andre Vehreschild * Email: vehre ad gmx dot de



-- 
Outside of a dog, a book is a man's best friend. Inside of a dog it's
too dark to read.

Groucho Marx