[Bug fortran/104570] [12 Regression] ICE in gfc_conv_scalarized_array_ref, at fortran/trans-array.cc:3681 since r12-7217-g57da34939703a6e6

["cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104570

--- Comment #4 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Mikael Morin <mikael@gcc.gnu.org>:

https://gcc.gnu.org/g:907811ddc35da6c1701ed22355ece63a8c3ed7fb

commit r12-7726-g907811ddc35da6c1701ed22355ece63a8c3ed7fb
Author: Mikael Morin <mikael@gcc.gnu.org>
Date:   Sun Mar 13 22:22:55 2022 +0100

    fortran: Separate associate character lengths earlier [PR104570]

    This change workarounds an ICE in the evaluation of the character length
    of an array expression referencing an associate variable; the code is
    not prepared to see a non-scalar expression as it doesnât initialize the
    scalarizer.

    Before this change, associate length symbols get a new gfc_charlen at
    resolution stage to unshare them from the associate expression, so that
    at translation stage it is a decl specific to the associate symbol that
    is initialized, not the decl of some other symbol.  This
    reinitialization of gfc_charlen happens after expressions referencing
    the associate symbol have been parsed, so that those expressions retain
    the original gfc_charlen they have copied from the symbol.
    At translation stage, the gfc_charlen for the associate symbol is setup
    with the decl holding the actual length value, but the expressions have
    retained the original gfc_charlen without any decl.  So they need to
    evaluate the character length, and this is where the ICE happens.

    This change moves the reinitialization of gfc_charlen earlier at parsing
    stage, so that at resolution stage the gfc_charlen can be retained as
    itâs already not shared with any other symbol, and the expressions which
    now share their gfc_charlen with the symbol are automatically updated
    when the length decl is setup at translation stage.  There is no need
    any more to evaluate the character length as it has all the required
    information, and the ICE doesnât happen.

    The first resolve.cc hunk is necessary to avoid regressing on the
    associate_35.f90 testcase.

            PR fortran/104228
            PR fortran/104570

    gcc/fortran/ChangeLog:

            * parse.cc (parse_associate): Use a new distinct gfc_charlen if the
            copied type has one whose length is not known to be constant.
            * resolve.cc (resolve_assoc_var): Reset charlen if itâs shared
with
            the associate target regardless of the expression type.
            Donât reinitialize charlen if itâs deferred.

    gcc/testsuite/ChangeLog:

            * gfortran.dg/associate_58.f90: New test.