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

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

[gscfq@t-online.de]

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

            Bug ID: 104570
           Summary: [12 Regression] ICE in gfc_conv_scalarized_array_ref,
                    at fortran/trans-array.cc:3681
           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: ---

Changed recently between 20220206 and 20220213 :


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


$ gfortran-12-20220213 -c z1.f90
z1.f90:9:22:

    9 |             print *, z
      |                      1
internal compiler error: Segmentation fault
0xcc8a9f crash_signal
        ../../gcc/toplev.cc:322
0x7ac696 gfc_conv_scalarized_array_ref
        ../../gcc/fortran/trans-array.cc:3681
0x7ad18c gfc_conv_array_ref(gfc_se*, gfc_array_ref*, gfc_expr*, locus*)
        ../../gcc/fortran/trans-array.cc:3832
0x7dc19e gfc_conv_variable
        ../../gcc/fortran/trans-expr.cc:3097
0x7d857a gfc_conv_expr(gfc_se*, gfc_expr*)
        ../../gcc/fortran/trans-expr.cc:9406
0x7dc779 gfc_conv_string_length(gfc_charlen*, gfc_expr*, stmtblock_t*)
        ../../gcc/fortran/trans-expr.cc:2551
0x7b7877 get_array_charlen
        ../../gcc/fortran/trans-array.cc:7353
0x7b798e get_array_charlen
        ../../gcc/fortran/trans-array.cc:7280
0x7b6d96 gfc_conv_expr_descriptor(gfc_se*, gfc_expr*)
        ../../gcc/fortran/trans-array.cc:7680
0x81c9da trans_associate_var
        ../../gcc/fortran/trans-stmt.cc:1918
0x823761 gfc_trans_block_construct(gfc_code*)
        ../../gcc/fortran/trans-stmt.cc:2312
0x7a76e7 trans_code
        ../../gcc/fortran/trans.cc:2012
0x8236ef gfc_trans_block_construct(gfc_code*)
        ../../gcc/fortran/trans-stmt.cc:2305
0x7a76e7 trans_code
        ../../gcc/fortran/trans.cc:2012
0x7d093e gfc_generate_function_code(gfc_namespace*)
        ../../gcc/fortran/trans-decl.cc:7654
0x7d076c gfc_generate_contained_functions
        ../../gcc/fortran/trans-decl.cc:5777
0x7d076c gfc_generate_function_code(gfc_namespace*)
        ../../gcc/fortran/trans-decl.cc:7586
0x75367e translate_all_program_units
        ../../gcc/fortran/parse.cc:6651
0x75367e gfc_parse_file()
        ../../gcc/fortran/parse.cc:6938
0x7a066f gfc_be_parse_file
        ../../gcc/fortran/f95-lang.cc:216

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

[gscfq@t-online.de]

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

G. Steinmetz <gscfq@t-online.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice-on-valid-code

--- Comment #1 from G. Steinmetz <gscfq@t-online.de> ---

Please note, no ICE with these variants :


$ cat z3.f90
program p
   character(:), allocatable :: x(:)
   x = ['abc']
   call s
contains
   subroutine s
      associate (y => x)
         associate (z => y)
            print *, z
         end associate
      end associate
   end
end


$ cat z4.f90
program p
   character(:), allocatable :: x(:)
   call s
contains
   subroutine s
      associate (y => x)
         associate (z => y)
            print *, z
         end associate
      end associate
   end
end


$ cat z5.f90
program p
   character(3) :: x(2)
   call s
contains
   subroutine s
      associate (y => x)
         associate (z => (y))
            print *, z
         end associate
      end associate
   end
end


$ cat z6.f90
program p
   character, allocatable :: x(:)
   call s
contains
   subroutine s
      associate (y => x)
         associate (z => (y))
            print *, z
         end associate
      end associate
   end
end


$ cat z7.f90
program p
   character, allocatable :: x(:)
   x = ['a']
   call s
contains
   subroutine s
      associate (y => x)
         associate (z => (y))
            print *, z
         end associate
      end associate
   end
end

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

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P4
   Target Milestone|---                         |12.0

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

[marxin at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |marxin at gcc dot gnu.org,
                   |                            |mikael at gcc dot gnu.org
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2022-02-24
            Summary|[12 Regression] ICE in      |[12 Regression] ICE in
                   |gfc_conv_scalarized_array_r |gfc_conv_scalarized_array_r
                   |ef, at                      |ef, at
                   |fortran/trans-array.cc:3681 |fortran/trans-array.cc:3681
                   |                            |since
                   |                            |r12-7217-g57da34939703a6e6
             Status|UNCONFIRMED                 |NEW

--- Comment #2 from Martin Liška <marxin at gcc dot gnu.org> ---
Started with r12-7217-g57da34939703a6e6.

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

[mikael at gcc dot gnu.org]

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

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

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

--- Comment #3 from Mikael Morin <mikael at gcc dot gnu.org> ---
Created attachment 52521
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52521&action=edit
Draft patch, regtests cleanly

My bug, I guess.
Here is a (very ad hoc) fix.
I have yet to see how much of it is really necessary, and whether I want this
rather than reverting the regressing revision.

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

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.

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

[mikael at gcc dot gnu.org]

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

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

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

--- Comment #5 from Mikael Morin <mikael at gcc dot gnu.org> ---
Fixed.

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

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

--- Comment #6 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/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]

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

--- Comment #7 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/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]

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

--- Comment #8 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)