Hi Paul,
> The fix for PR9601 is rather trivial and is the last chunk of the patch.
> Finding the fix for PR96100 took a silly amount of time but it now looks
> rather obvious. Trying to evaluate the string length by calling
> gfc_conv_expr_descriptor, when this function is already failing to find it
> is kind of doomed to failure :-) Therefore, gfc_conv_expr is used with
> tse.descriptor_only set. This has the effect of ignoring trailing array
> references and making use of gfc_conv_component_ref's being able to extract
> the hidden string length for deferred length components. Finally, the
> string length of the first element in the array constructor is set if this
> is a deferred length component.
The patch seems to be effective. Albeit I don't understand why, when it is a
parenthesis op, you deduce that this has to be the string length?
The explanation for the second fix left me completely lost.
> Regtests OK on FC31/x86_64 - OK for master?
Tests ok with no regression. Therefore ok by me.
Regards,
Andre
>
> Paul
>
> This patch fixes PR96100 and PR96101 by making some minor changes to
> the evaluation of string lengths for gfc_conv_expr_descriptor.
>
> 2020-08-13 Paul Thomas <pa...@gcc.gnu.org>
>
> gcc/fortran
> PR fortran/96100
> PR fortran/96101
> * trans-array.c (get_array_charlen): Tidy up the evaluation of
> the string length for array constructors. Avoid trailing array
> references. Ensure string lengths of deferred length components
> are set. For parentheses operator apply string length to both
> the primary expression and the enclosed expression.
>
> gcc/testsuite/
> PR fortran/96100
> PR fortran/96101
> * gfortran.dg/char_length_23.f90: New test.
--
Andre Vehreschild * Email: vehre ad gmx dot de
