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 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

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

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

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

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,

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

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 PR

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

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

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

Hi Andre, Thanks for a quick response: > You can use > >|| (e->symtree && UNLIMITED_POLY (e->symtree->n.sym)); Ah yes, you are quite right. > here. UNLIMITED_POLY does all the checks. I am still wondering whether this is > necessary? The symtree is set for expr_type == { EXPR_VARIABLE,

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

Hi Paul, > Index: gcc/fortran/trans-stmt.c > === > *** gcc/fortran/trans-stmt.c (revision 241273) > --- gcc/fortran/trans-stmt.c (working copy) > *** trans_associate_var (gfc_symbol *sym, gf > *** 1517,1523 >

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

Dear All, This bug was caused by 'associate name' and 'associate entity' expressions being incomplete when the 'selector' was an intrinsic function result. I tried to fix this at source, in match_select _type and gfc_get_variable_expr, but caused a vast number of breakages. Undoubtedly, this