Hi Andre, Committed to trunk as revision 241403.
Thanks for the review. Paul On 20 October 2016 at 11:43, Andre Vehreschild <ve...@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 <ve...@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.tho...@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 <pa...@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 <pa...@gcc.gnu.org> >> > >> > PR fortran/69566 >> > * gfortran.dg/select_type_37.f03: New test. >> > >> > On 18 October 2016 at 18:16, Andre Vehreschild <ve...@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
