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

[Andre Vehreschild]

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 ****
>   		    && (gfc_is_class_scalar_expr (e)
>   			|| gfc_is_class_array_ref (e, NULL));
> 
> !   unlimited = UNLIMITED_POLY (e);
> 
>     /* Assignments to the string length need to be generated, when
>        ( sym is a char array or
> --- 1517,1526 ----
>   		    && (gfc_is_class_scalar_expr (e)
>   			|| gfc_is_class_array_ref (e, NULL));
> 
> !   unlimited = UNLIMITED_POLY (e)
> ! 		|| (e->symtree && e->symtree->n.sym
> ! 		    && e->symtree->n.sym->ts.type == BT_CLASS
> ! 		    && UNLIMITED_POLY (e->symtree->n.sym));> 

You can use 

   || (e->symtree && UNLIMITED_POLY (e->symtree->n.sym));

here. UNLIMITED_POLY does all the checks. I am still wondering whether this is
necessary? The symtree is set for expr_type == { EXPR_VARIABLE, EXPR_FUNCTION }
both of those should correctly resolve to an unlimited poly ts. Is this a
left-over? 

I am regression testing my polymorhpic class patch at the moment, therefore I
can't test.

> 
>     /* Assignments to the string length need to be generated, when
>        ( sym is a char array or

- Andre

On Tue, 18 Oct 2016 16:29:54 +0200
Paul Richard Thomas <paul.richard.thomas@gmail.com> wrote:


> 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 would be the ecologically sound way to proceed but
> applying fixups in resolve_select_type, gfc_conv_class_to_class and
> trans_associate_var proved to be the path of least resistance.
> 
> Depending on which form of select type is used, the defective
> expressions either lacked the correct value for rank, a full array
> reference, a symbol with an array spec or had type BT_DERIVED for a
> polymorphic symbol; these either singly or in combination depending of
> the form of select type.
> 
> The patch, taken with the ChangeLogs, is fairly self-explanatory.
> Please note that I have suppressed whitespace changes (suppression of
> trailing blanks), so use patch with the -l option.
> 
> Bootstraps and regtests on FC21/x86_64 - OK for trunk?
> 
> Best regards
> 
> Paul
> 
> 2016-10-18  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.
>     * trans-stmt.c (trans_associate_var): Extend 'unlimited' to
>     include expressions which are themsleves not unlimited
>     polymorphic but the symbol is.
> 
> 2016-10-18  Paul Thomas  <pault@gcc.gnu.org>
> 
>     PR fortran/69566
>     * gfortran.dg/select_type_37.f03: New test.


-- 
Andre Vehreschild * Email: vehre ad gmx dot de