public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/104228] [9/10/11 Regression] ICE in df_install_ref, at df-scan.cc:2294 since r8-3589-g707905d0773e5a8e
Date: Mon, 09 May 2022 11:22:36 +0000	[thread overview]
Message-ID: <bug-104228-4-shxddzYd1W@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-104228-4@http.gcc.gnu.org/bugzilla/>

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

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

https://gcc.gnu.org/g:3a426e474125c37e5f5268aaa42600b0ef4192e4

commit r9-10049-g3a426e474125c37e5f5268aaa42600b0ef4192e4
Author: Mikael Morin <mikael@gcc.gnu.org>
Date:   Fri Jan 28 22:00:57 2022 +0100

    fortran: Backport associate character length fixes [PR104228]

    Backport commits:
    r12-7217-g57da34939703a6e6d3267a0d25d1fb9369d3ac0e
    r12-7726-g907811ddc35da6c1701ed22355ece63a8c3ed7fb

    --

    fortran: Unshare associate var charlen [PR104228]

    PR104228 showed that character lengths were shared between associate
    variable and associate targets.  This is problematic when the associate
    target is itself a variable and gets a variable to hold the length, as
    the length variable is added (and all the variables following it in the
chain)
    to both the associate variable scope and the target variable scope.
    This caused an ICE when compiling with -O0 -fsanitize=address.

    This change forces the creation of a separate character length for the
    associate variable.  It also forces the initialization of the character
    length variable to avoid regressing associate_32 and associate_47 tests.

    --

    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.c hunk is necessary to avoid regressing on the
    associate_35.f90 testcase.

    --

            PR fortran/104228
            PR fortran/104570

    gcc/fortran/ChangeLog:

            * parse.c (parse_associate): Use a new distinct gfc_charlen if
            the copied type has one whose length is not known to be
            constant.
            * resolve.c (resolve_assoc_var): Also create a new character
            length for non-dummy associate targets.  Reset charlen if itâs
            shared with the associate target regardless of the expression
            type.  Donât reinitialize charlen if itâs deferred.
            * trans-stmt.c (trans_associate_var): Initialize character
            length even if no temporary is used for the associate variable.

    gcc/testsuite/ChangeLog:

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

    (cherry picked from commit 4c8e037d32e91c0ec4ac577d1d0723ab9d6ec809)

  parent reply	other threads:[~2022-05-09 11:22 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-25 18:04 [Bug fortran/104228] New: [9/10/11/12 Regression] ICE in df_install_ref, at df-scan.cc:2294 gscfq@t-online.de
2022-01-26  7:49 ` [Bug fortran/104228] " rguenth at gcc dot gnu.org
2022-01-26  8:25 ` [Bug fortran/104228] [9/10/11/12 Regression] ICE in df_install_ref, at df-scan.cc:2294 since r8-3589-g707905d0773e5a8e marxin at gcc dot gnu.org
2022-01-28 15:42 ` jakub at gcc dot gnu.org
2022-01-28 15:52 ` jakub at gcc dot gnu.org
2022-01-28 16:19 ` jakub at gcc dot gnu.org
2022-01-28 21:19 ` mikael at gcc dot gnu.org
2022-02-13 16:01 ` cvs-commit at gcc dot gnu.org
2022-03-09 13:22 ` [Bug fortran/104228] [9/10/11 " rguenth at gcc dot gnu.org
2022-03-19 20:17 ` cvs-commit at gcc dot gnu.org
2022-04-10 18:48 ` cvs-commit at gcc dot gnu.org
2022-04-10 18:48 ` cvs-commit at gcc dot gnu.org
2022-04-24 16:54 ` cvs-commit at gcc dot gnu.org
2022-05-09 11:22 ` cvs-commit at gcc dot gnu.org [this message]
2022-05-09 11:27 ` mikael at gcc dot gnu.org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-104228-4-shxddzYd1W@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).