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

Andre Vehreschild vehre@gmx.de
Thu Oct 20 09:43:00 GMT 2016


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 



More information about the Gcc-patches mailing list