[Patch, fortran] PRs 96100 and 96101 - Problems with string lengths of array constructors

Andre Vehreschild vehre@gmx.de
Mon Aug 17 16:39:23 GMT 2020

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.

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

More information about the Gcc-patches mailing list