[Bug fortran/104228] New: [9/10/11/12 Regression] ICE in df_install_ref, at df-scan.cc:2294

[Bug fortran/104228] New: [9/10/11/12 Regression] ICE in df_install_ref, at df-scan.cc:2294

[gscfq@t-online.de]

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

            Bug ID: 104228
           Summary: [9/10/11/12 Regression] ICE in df_install_ref, at
                    df-scan.cc:2294
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: gscfq@t-online.de
  Target Milestone: ---

Affects versions down to r8 :


$ cat z1.f90
program p
   character(:), save, allocatable :: x(:)
   call s
contains
   subroutine s
      associate (y => x)
         y = [x]
      end associate
   end
end


$ cat z2.f90
program p
   character(:), allocatable :: x(:)
   call s
contains
   subroutine s
      associate (y => x)
         y = [x]
      end associate
   end
end


$ gfortran-12-20220123 -c z1.f90 -fsanitize=address
during RTL pass: no-opt dfinit
z1.f90:3:9:

    3 |    call s
      |         ^
internal compiler error: Segmentation fault
0xe6bd5f crash_signal
        ../../gcc/toplev.cc:322
0x98c58f df_install_ref
        ../../gcc/df-scan.cc:2294
0x98c707 df_install_refs
        ../../gcc/df-scan.cc:2375
0x98c87e df_refs_add_to_chains
        ../../gcc/df-scan.cc:2429
0x994b75 df_bb_refs_record(int, bool)
        ../../gcc/df-scan.cc:3351
0x9951a4 df_scan_blocks()
        ../../gcc/df-scan.cc:588
0x97df85 rest_of_handle_df_initialize
        ../../gcc/df-core.cc:715
0x97df85 execute
        ../../gcc/df-core.cc:747

... or other backtraces

[Bug fortran/104228] [9/10/11/12 Regression] ICE in df_install_ref, at df-scan.cc:2294

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Target Milestone|---                         |9.5
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2022-01-26

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
(gdb) p debug_rtx (insn)
(insn 5 2 6 2 (parallel [
            (set (reg:DI 94)
                (plus:DI (reg:DI 244)
                    (const_int -112 [0xffffffffffffff90])))
            (clobber (reg:CC 17 flags))
        ]) "t.f90":1:9 230 {*adddi_1}
     (nil))

and we reference reg 244 but reg_info for this reg is NULL.  The insn is the
first in the BB and reg:DI 244 doesn't seem to be initialized.

The instruction is expanded from

;; _10 = &FRAME.16.FRAME_BASE.PARENT;

(insn 5 4 6 (parallel [
            (set (reg:DI 94)
                (plus:DI (reg:DI 244)
                    (const_int -112 [0xffffffffffffff90])))
            (clobber (reg:CC 17 flags))
        ]) "t.f90":1:9 -1
     (nil)) 

(insn 6 5 0 (parallel [
            (set (reg/f:DI 88 [ _10 ])
                (plus:DI (reg:DI 94)
                    (const_int 64 [0x40])))
            (clobber (reg:CC 17 flags))
        ]) "t.f90":1:9 -1
     (nil))

and the underlying issue is a shared FRAME.16 local used in two functions
I think:

__attribute__((fn spec (". ")))
voidD.27 sD.4214 ()
{
..
  struct FRAME.p FRAME.16D.4307;


...
__attribute__((fn spec (". ")))
voidD.27 pD.4212 ()
{
  struct FRAME.p FRAME.16D.4307;
...
  struct array01_character(kind=1) yD.4238 [value-expr:
FRAME.16D.4307.yD.4308];

where the frame is unused in 's' but likely expanded there and then
the expansion is used in the wrong function.

Without asan the references are likely optimized away.


Note in .original from the FE we see the shared variable is 'y':

void s ()
{
  {
    static integer(kind=8)D.9 .yD.4216;
    struct array01_character(kind=1) yD.4238;
...

void p ()
{
  static voidD.27 sD.4214 (void);
  struct array01_character(kind=1) yD.4238;
...

where that 'y' is unused in 'p'.

[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]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[9/10/11/12 Regression] ICE |[9/10/11/12 Regression] ICE
                   |in df_install_ref, at       |in df_install_ref, at
                   |df-scan.cc:2294             |df-scan.cc:2294 since
                   |                            |r8-3589-g707905d0773e5a8e
                 CC|                            |marxin at gcc dot gnu.org,
                   |                            |pault at gcc dot gnu.org

--- Comment #2 from Martin Liška <marxin at gcc dot gnu.org> ---
Started with r8-3589-g707905d0773e5a8e.

[Bug fortran/104228] [9/10/11/12 Regression] ICE in df_install_ref, at df-scan.cc:2294 since r8-3589-g707905d0773e5a8e

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Seems to be a FE bug.
Already in *.gimple bug with -fdump-tree-all-uid one can see:
__attribute__((fn spec (". ")))
void p ()
{
  static voidD.27 sD.4214 (void);
  struct array01_character(kind=1) yD.4238;
  static integer(kind=8)D.9 .yD.4216;
  static struct array01_character(kind=1) xD.4249 = {.dataD.4244=0B};
  bitsizetype D.4278;
  sizetype D.4279;

  try
    {
...
__attribute__((fn spec (". ")))
void s ()
{
  bitsizetype D.4285;
  sizetype .y.10D.4286;
  integer(kind=8)D.9 iftmp.14D.4287;

  {
    static integer(kind=8)D.9 .yD.4216;
    static struct array01_character(kind=1) xD.4249 = {.dataD.4244=0B};
    bitsizetype D.4278;
    sizetype D.4279;

That means that BLOCK_VARS of a BLOCK inside of p function contain
s var with DECL_UID 4214, its DECL_CHAIN is y with DECL_UID 4238 and
its DECL_CHAIN is .y with DECL_UID 4216.
But the same .y var with DECL_UID 4216 is also in BLOCK_VARS of another BLOCK
inside of s.  Vars in BLOCK_VARS are chained through DECL_CHAIN, aren't in some
vec or TREE_VEC etc., so can't be part of multiple chains.

[Bug fortran/104228] [9/10/11/12 Regression] ICE in df_install_ref, at df-scan.cc:2294 since r8-3589-g707905d0773e5a8e

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The .y var is added into the s function with:
#0  add_decl_as_local (decl=<var_decl 0x7fffea24ab40 .y>) at
../../gcc/fortran/trans-decl.cc:257
#1  0x0000000000c054f8 in gfc_finish_var_decl (decl=<var_decl 0x7fffea24ab40
.y>, sym=0x3e16a00) at ../../gcc/fortran/trans-decl.cc:649
#2  0x0000000000c09e9e in gfc_get_symbol_decl (sym=0x3e16a00) at
../../gcc/fortran/trans-decl.cc:1882
#3  0x0000000000c18dee in generate_local_decl (sym=0x3e16a00) at
../../gcc/fortran/trans-decl.cc:5853
#4  0x0000000000bb5174 in do_traverse_symtree (st=0x3e16b60, st_func=0x0,
sym_func=0xc18d2a <generate_local_decl(gfc_symbol*)>) at
../../gcc/fortran/symbol.cc:4174
#5  0x0000000000bb522f in gfc_traverse_ns (ns=0x3e19810, sym_func=0xc18d2a
<generate_local_decl(gfc_symbol*)>) at ../../gcc/fortran/symbol.cc:4199
#6  0x0000000000c19780 in generate_local_vars (ns=0x3e19810) at
../../gcc/fortran/trans-decl.cc:6064
#7  0x0000000000c20fae in gfc_process_block_locals (ns=0x3e19810) at
../../gcc/fortran/trans-decl.cc:7940
#8  0x0000000000ca8b60 in gfc_trans_block_construct (code=0x3e16ba0) at
../../gcc/fortran/trans-stmt.cc:2296
#9  0x0000000000bd8645 in trans_code (code=0x3e16ba0, cond=<tree 0x0>) at
../../gcc/fortran/trans.cc:2012
#10 0x0000000000bd8a58 in gfc_trans_code (code=0x3e16ba0) at
../../gcc/fortran/trans.cc:2268
#11 0x0000000000c203ea in gfc_generate_function_code (ns=0x3e15530) at
../../gcc/fortran/trans-decl.cc:7654
#12 0x0000000000c18b5d in gfc_generate_contained_functions (parent=0x3e14530)
at ../../gcc/fortran/trans-decl.cc:5777
#13 0x0000000000c20031 in gfc_generate_function_code (ns=0x3e14530) at
../../gcc/fortran/trans-decl.cc:7586
#14 0x0000000000bd8a9c in gfc_generate_code (ns=0x3e14530) at
../../gcc/fortran/trans.cc:2285
#15 0x0000000000b5ca50 in translate_all_program_units
(gfc_global_ns_list=0x3e14530) at ../../gcc/fortran/parse.cc:6651
#16 0x0000000000b5d299 in gfc_parse_file () at ../../gcc/fortran/parse.cc:6938
#17 0x0000000000bc0539 in gfc_be_parse_file () at
../../gcc/fortran/f95-lang.cc:216
#18 0x0000000001463e4f in compile_file () at ../../gcc/toplev.cc:452
#19 0x0000000001466e45 in do_compile (no_backend=false) at
../../gcc/toplev.cc:2158
#20 0x000000000146720a in toplev::main (this=0x7fffffffd76a, argc=4,
argv=0x7fffffffd878) at ../../gcc/toplev.cc:2310
#21 0x0000000002b3c444 in main (argc=4, argv=0x7fffffffd878) at
../../gcc/main.cc:39
and then pushdecl is called on it too:
#0  pushdecl (decl=<var_decl 0x7fffea24ab40 .y>) at
../../gcc/fortran/f95-lang.cc:442
#1  0x0000000000c21086 in gfc_process_block_locals (ns=0x3e19810) at
../../gcc/fortran/trans-decl.cc:7952
#2  0x0000000000ca8b60 in gfc_trans_block_construct (code=0x3e16ba0) at
../../gcc/fortran/trans-stmt.cc:2296
#3  0x0000000000bd8645 in trans_code (code=0x3e16ba0, cond=<tree 0x0>) at
../../gcc/fortran/trans.cc:2012
#4  0x0000000000bd8a58 in gfc_trans_code (code=0x3e16ba0) at
../../gcc/fortran/trans.cc:2268
#5  0x0000000000c203ea in gfc_generate_function_code (ns=0x3e15530) at
../../gcc/fortran/trans-decl.cc:7654
#6  0x0000000000c18b5d in gfc_generate_contained_functions (parent=0x3e14530)
at ../../gcc/fortran/trans-decl.cc:5777
#7  0x0000000000c20031 in gfc_generate_function_code (ns=0x3e14530) at
../../gcc/fortran/trans-decl.cc:7586
#8  0x0000000000bd8a9c in gfc_generate_code (ns=0x3e14530) at
../../gcc/fortran/trans.cc:2285
#9  0x0000000000b5ca50 in translate_all_program_units
(gfc_global_ns_list=0x3e14530) at ../../gcc/fortran/parse.cc:6651
#10 0x0000000000b5d299 in gfc_parse_file () at ../../gcc/fortran/parse.cc:6938
#11 0x0000000000bc0539 in gfc_be_parse_file () at
../../gcc/fortran/f95-lang.cc:216
#12 0x0000000001463e4f in compile_file () at ../../gcc/toplev.cc:452
#13 0x0000000001466e45 in do_compile (no_backend=false) at
../../gcc/toplev.cc:2158
#14 0x000000000146720a in toplev::main (this=0x7fffffffd76a, argc=4,
argv=0x7fffffffd878) at ../../gcc/toplev.cc:2310
#15 0x0000000002b3c444 in main (argc=4, argv=0x7fffffffd878) at
../../gcc/main.cc:39
with cfun->decl of s and once again in:
#0  pushdecl (decl=<var_decl 0x7fffea24ab40 .y>) at
../../gcc/fortran/f95-lang.cc:442
#1  0x0000000000c20b7e in gfc_generate_function_code (ns=0x3e14530) at
../../gcc/fortran/trans-decl.cc:7768
#2  0x0000000000bd8a9c in gfc_generate_code (ns=0x3e14530) at
../../gcc/fortran/trans.cc:2285
#3  0x0000000000b5ca50 in translate_all_program_units
(gfc_global_ns_list=0x3e14530) at ../../gcc/fortran/parse.cc:6651
#4  0x0000000000b5d299 in gfc_parse_file () at ../../gcc/fortran/parse.cc:6938
#5  0x0000000000bc0539 in gfc_be_parse_file () at
../../gcc/fortran/f95-lang.cc:216
#6  0x0000000001463e4f in compile_file () at ../../gcc/toplev.cc:452
#7  0x0000000001466e45 in do_compile (no_backend=false) at
../../gcc/toplev.cc:2158
#8  0x000000000146720a in toplev::main (this=0x7fffffffd76a, argc=4,
argv=0x7fffffffd878) at ../../gcc/toplev.cc:2310
#9  0x0000000002b3c444 in main (argc=4, argv=0x7fffffffd878) at
../../gcc/main.cc:39
with cfun->decl of p.

[Bug fortran/104228] [9/10/11/12 Regression] ICE in df_install_ref, at df-scan.cc:2294 since r8-3589-g707905d0773e5a8e

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
If the testcase is extended to:
program p
   character(:), save, allocatable :: x(:)
   call s1
   call s2
   call s3
   call s4
contains
   subroutine s1
      associate (y1 => x)
         y1 = [x]
      end associate
   end
   subroutine s2
      associate (y2 => x)
         y2 = [x]
      end associate
   end
   subroutine s3
      associate (y3 => x)
         y3 = [x]
      end associate
   end
   subroutine s4
      associate (y4 => x)
         y4 = [x]
      end associate
   end
end

then the p program contains just one of those y vars (y4/.y4):
__attribute__((fn spec (". ")))
void p ()
{
  static voidD.27 s4D.4214 (void);
  static voidD.27 s3D.4216 (void);
  static voidD.27 s2D.4218 (void);
  static voidD.27 s1D.4220 (void);
  struct array01_character(kind=1) y4D.4244;
  static integer(kind=8)D.9 .y4D.4222;
  static struct array01_character(kind=1) xD.4255 = {.dataD.4250=0B};
  bitsizetype D.4401;
  sizetype D.4402;

  D.4401 = (bitsizetype) (sizetype) NON_LVALUE_EXPR <.y4D.4222> * 8;
  D.4402 = (sizetype) NON_LVALUE_EXPR <.y4D.4222>;
  s1D.4220 ();
  s2D.4218 ();
  s3D.4216 ();
  s4D.4214 ();
}

Now, if that .y4 randomly called based on one of the associate users is just
named character length of the x
array (shouldn't it be called .x ?) of a SAVE var in p, I'd think it should go
to the BLOCK where x is defined and nowhere else, all the nested functions (==
contained subroutines) should refer to it non-locally and shouldn't have it in
its BLOCK_VARS.

[Bug fortran/104228] [9/10/11/12 Regression] ICE in df_install_ref, at df-scan.cc:2294 since r8-3589-g707905d0773e5a8e

[mikael at gcc dot gnu.org]

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

Mikael Morin <mikael at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mikael at gcc dot gnu.org
           Assignee|unassigned at gcc dot gnu.org      |mikael at gcc dot gnu.org
             Status|NEW                         |ASSIGNED

--- Comment #6 from Mikael Morin <mikael at gcc dot gnu.org> ---
The full typespec is copied from the associate target (x) to the associate
symbol (y) at parse.cc:4925.  This includes the character length object, which
starting from there is shared between x and y.  None of the various conditions
are met in resolve_assoc_var to overwrite the character length object.  So when
we create the length decl (.y) for y and store it in its character length
object, it also appears in that of x at the same time.  And from there it is
added to both functions along a path that I have lost.

Draft patch:

diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 835a4783718..266e41e25b1 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -9227,7 +9227,6 @@ resolve_assoc_var (gfc_symbol* sym, bool resolve_target)
        sym->ts.u.cl = target->ts.u.cl;

       if (sym->ts.deferred && target->expr_type == EXPR_VARIABLE
-         && target->symtree->n.sym->attr.dummy
          && sym->ts.u.cl == target->ts.u.cl)
        {
          sym->ts.u.cl = gfc_new_charlen (sym->ns, NULL);

[Bug fortran/104228] [9/10/11/12 Regression] ICE in df_install_ref, at df-scan.cc:2294 since r8-3589-g707905d0773e5a8e

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 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:57da34939703a6e6d3267a0d25d1fb9369d3ac0e

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

    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.

            PR fortran/104228

    gcc/fortran/ChangeLog:

            * resolve.cc (resolve_assoc_var): Also create a new character
            length for non-dummy associate targets.
            * trans-stmt.cc (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.

[Bug fortran/104228] [9/10/11 Regression] ICE in df_install_ref, at df-scan.cc:2294 since r8-3589-g707905d0773e5a8e

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[9/10/11/12 Regression] ICE |[9/10/11 Regression] ICE in
                   |in df_install_ref, at       |df_install_ref, at
                   |df-scan.cc:2294 since       |df-scan.cc:2294 since
                   |r8-3589-g707905d0773e5a8e   |r8-3589-g707905d0773e5a8e
           Priority|P3                          |P4
      Known to work|                            |12.0

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed on trunk sofar.

[Bug fortran/104228] [9/10/11 Regression] ICE in df_install_ref, at df-scan.cc:2294 since r8-3589-g707905d0773e5a8e

[cvs-commit at gcc dot gnu.org]

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

--- Comment #9 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.

[Bug fortran/104228] [9/10/11 Regression] ICE in df_install_ref, at df-scan.cc:2294 since r8-3589-g707905d0773e5a8e

[cvs-commit at gcc dot gnu.org]

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

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

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

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

    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.

            PR fortran/104228

    gcc/fortran/ChangeLog:

            * resolve.c (resolve_assoc_var): Also create a new character
            length for non-dummy associate targets.
            * 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.

    (cherry picked from commit 57da34939703a6e6d3267a0d25d1fb9369d3ac0e)

[Bug fortran/104228] [9/10/11 Regression] ICE in df_install_ref, at df-scan.cc:2294 since r8-3589-g707905d0773e5a8e

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:6b4e07251c685430e00d6b3f3dee41012c41ca26

commit r11-9805-g6b4e07251c685430e00d6b3f3dee41012c41ca26
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.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): 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.

    (cherry picked from commit 907811ddc35da6c1701ed22355ece63a8c3ed7fb)

[Bug fortran/104228] [9/10/11 Regression] ICE in df_install_ref, at df-scan.cc:2294 since r8-3589-g707905d0773e5a8e

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:4c8e037d32e91c0ec4ac577d1d0723ab9d6ec809

commit r10-10554-g4c8e037d32e91c0ec4ac577d1d0723ab9d6ec809
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.

[Bug fortran/104228] [9/10/11 Regression] ICE in df_install_ref, at df-scan.cc:2294 since r8-3589-g707905d0773e5a8e

[cvs-commit at gcc dot gnu.org]

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)

[Bug fortran/104228] [9/10/11 Regression] ICE in df_install_ref, at df-scan.cc:2294 since r8-3589-g707905d0773e5a8e

[mikael at gcc dot gnu.org]

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

Mikael Morin <mikael at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|ASSIGNED                    |RESOLVED

--- Comment #14 from Mikael Morin <mikael at gcc dot gnu.org> ---
Fixed for releases 9.5, 10.4, 11.3 and 12.1.
Closing.
Thanks for the report.