This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Patch, fortran] PR69566 - Failure of SELECT TYPE with unlimited polymorphic function result


Hi Andre,

Committed to trunk as revision 241403.

Thanks for the review.

Paul

On 20 October 2016 at 11:43, Andre Vehreschild <vehre@gmx.de> wrote:
> Hi Paul,
>
> after looking at your patch again, I understood why these extra copies are
> needed. May be a comment would prevent future gfortran hackers from trying to
> remove them again.
>
> The patch is ok for me. Thanks for working on this.
>
> Regards,
>         Andre
>
>
> On Wed, 19 Oct 2016 20:02:14 +0200
> Andre Vehreschild <vehre@gmx.de> wrote:
>
>> Hi Paul,
>>
>> I am not completely through with your patch, but what jumped into my eye was
>> that you copy ref in resolve_select_type and again in fixup_array_ref, when
>> you use it? May be I oversee something. You are more into this code. Is the
>> double copying necessary (line 49 and 82 as well as 95, respectively). IMHO
>> the copy in line 49 could be sufficient.
>>
>> I look into it tomorrow more thoroughly. Please wait before submitting a new
>> version. May be I see something more :-)
>>
>> So far, thanks for working on this.
>>
>> Regards,
>>       Andre
>>
>> On Wed, 19 Oct 2016 09:28:39 +0200
>> Paul Richard Thomas <paul.richard.thomas@gmail.com> wrote:
>>
>> > Dear Andre,
>> >
>> > Following our exchange yesterday, I have eliminated the modification
>> > to trans_associate_var and have corrected the offending expressions in
>> > resolve.c(fixup_array_ref).
>> >
>> > Please find attached the corrected patch.
>> >
>> > Cheers
>> >
>> > Paul
>> >
>> > 2016-10-19  Paul Thomas  <pault@gcc.gnu.org>
>> >
>> >     PR fortran/69566
>> >     * resolve.c (fixup_array_ref): New function.
>> >     (resolve_select_type): Gather up the rank and array reference,
>> >     if any, from the selector. Fix up the 'associate name' and the
>> >     'associate entities' as necessary.
>> >     * trans-expr.c (gfc_conv_class_to_class): If the symbol backend
>> >     decl is a FUNCTION_DECL, use the 'fake_result_decl' instead.
>> >
>> > 2016-10-19  Paul Thomas  <pault@gcc.gnu.org>
>> >
>> >     PR fortran/69566
>> >     * gfortran.dg/select_type_37.f03: New test.
>> >
>> > On 18 October 2016 at 18:16, Andre Vehreschild <vehre@gmx.de> wrote:
>> > > Hi Paul,
>> > >
>> > >> For reasons I don't understand, sometimes the expression type comes
>> > >> through as BT_DERIVED, whilst the symbol is BT_CLASS. I could repair
>> > >> this in resolve.c(fixup_array_ref) if you think that would be
>> > >> cleaner.
>> > >
>> > > I think that I figured the rule:
>> > >
>> > > - when no _class-ref is present, then the type is BT_CLASS,
>> > > - as soon as a _class-ref is present the type is BT_DERIVED.
>> > >
>> > > There is an attr.is_class. Would that be an alternative? I don't know how
>> > > reliable it is set.
>> > >
>> > >> > I am regression testing my polymorhpic class patch at the moment,
>> > >> > therefore I can't test.
>> > >>
>> > >> OK - I can wait. I have quite a few other things to do :-(
>> > >
>> > > I found an error in my patch that only manifests itself with an
>> > > optimization level great than 0. Now I am searching, never having done
>> > > anything there.
>> > >
>> > > - Andre
>> > > --
>> > > Andre Vehreschild * Email: vehre ad gmx dot de
>> >
>> >
>> >
>>
>>
>
>
> --
> Andre Vehreschild * Email: vehre ad gmx dot de



-- 
The difference between genius and stupidity is; genius has its limits.

Albert Einstein


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]