[Bug c/100508] New: ICE with '-g -O3': in expand_debug_locations, at cfgexpand.c:5618

[Bug c/100508] New: ICE with '-g -O3': in expand_debug_locations, at cfgexpand.c:5618

[cnsun at uwaterloo dot ca]

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

            Bug ID: 100508
           Summary: ICE with '-g -O3': in expand_debug_locations, at
                    cfgexpand.c:5618
           Product: gcc
           Version: tree-ssa
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: cnsun at uwaterloo dot ca
  Target Milestone: ---

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/scratch/software/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /tmp/tmp.FRQzt2wMfl-gcc-builder/gcc/configure
--enable-languages=c,c++,lto --enable-checking-yes --enable-multiarch
--prefix=/scratch/software/gcc-trunk --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210510 (experimental) [master revision
:fb3a8fb4a:25f9f35a85ffee808fc1482b14d91176df59751b] (GCC)

$ cat mutant.c
typedef __attribute__((__vector_size__(32))) V;
V j;
__attribute__((simd)) foo() { V m = j; }

$ gcc-trunk -g -O3 mutant.c
mutant.c:1:46: warning: type defaults to ‘int’ in declaration of ‘V’
[-Wimplicit-int]
    1 | typedef __attribute__((__vector_size__(32))) V;
      |                                              ^
mutant.c:3:23: warning: return type defaults to ‘int’ [-Wimplicit-int]
    3 | __attribute__((simd)) foo() { V m = j; }
      |                       ^~~
during RTL pass: expand
mutant.c: In function ‘foo.simdclone.2’:
mutant.c:3:23: internal compiler error: in expand_debug_locations, at
cfgexpand.c:5618
0x68c497 expand_debug_locations
        /tmp/tmp.FRQzt2wMfl-gcc-builder/gcc/gcc/cfgexpand.c:5618
0x68c497 execute
        /tmp/tmp.FRQzt2wMfl-gcc-builder/gcc/gcc/cfgexpand.c:6735
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

[Bug middle-end/100508] ICE with '-g -O3': in expand_debug_locations, at cfgexpand.c:5618

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice-on-valid-code, openmp
             Target|                            |x86_64-*-*
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2021-05-11
             Status|UNCONFIRMED                 |NEW
            Version|tree-ssa                    |12.0
                 CC|                            |jakub at gcc dot gnu.org
          Component|c                           |middle-end

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
#1  0x0000000000bb481f in expand_debug_locations ()
    at ../../src/gcc-11-branch/gcc/cfgexpand.c:5615
5615                gcc_assert (mode == GET_MODE (val)
(gdb) l
5610              val = gen_rtx_UNKNOWN_VAR_LOC ();
5611            else
5612              {
5613                mode = GET_MODE (INSN_VAR_LOCATION (insn));
5614
5615                gcc_assert (mode == GET_MODE (val)
5616                            || (GET_MODE (val) == VOIDmode
5617                                && (CONST_SCALAR_INT_P (val)
5618                                    || GET_CODE (val) == CONST_FIXED
5619                                    || GET_CODE (val) == LABEL_REF)));
(gdb) p debug_rtx (insn)
(debug_insn 10 9 11 3 (var_location:V8SI m (pc
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff68038f6 in __strlen_sse2 () from /lib64/libc.so.6
The program being debugged was signaled while in a function called from GDB.
GDB has restored the context to what it was before the call.
To change this behavior use "set unwindonsignal off".
Evaluation of the expression containing the function
(debug_rtx(rtx_def const*)) will be abandoned.

(gdb) p debug_rtx (val)
(debug_expr:BLK D#1)
(gdb) p mode
$3 = E_V8SImode

possibly some TYPE/DECL_MODE[_RAW] issue.

we have

(gdb) p debug_tree (value)
 <debug_expr_decl 0x7ffff6578b40 D.4294967295
    type <vector_type 0x7ffff669ee70 V
        type <integer_type 0x7ffff65835e8 int asm_written public SI
            size <integer_cst 0x7ffff656af18 constant 32>
            unit-size <integer_cst 0x7ffff656af30 constant 4>
            align:32 warn_if_not_align:0 symtab:-160677248 alias-set 1
canonical-type 0x7ffff65835e8 precision:32 min <integer_cst 0x7ffff656aed0
-2147483648> max <integer_cst 0x7ffff656aee8 2147483647>
            pointer_to_this <pointer_type 0x7ffff658b9d8>>
        sizes-gimplified asm_written V8SI
        size <integer_cst 0x7ffff6588048 constant 256>
        unit-size <integer_cst 0x7ffff6588138 constant 32>
        align:256 warn_if_not_align:0 symtab:-160677488 alias-set -1
canonical-type 0x7ffff668f738 nunits:8 context <translation_unit_decl
0x7ffff6578ac8 t.c>
        pointer_to_this <pointer_type 0x7ffff669e5e8>>
    visited BLK t.c:3:1
    align:1 warn_if_not_align:0
    (debug_expr:BLK D#1)>

so expand_debug_expr yields E_V8SImode from TYPE_MODE (TREE_TYPE (exp)) for
unknown reasons - targetm.vector_mode_supported_p returns true.

For some reason the debug stmt

  # DEBUG m => m_2

appears already in into-SSA and at that point SIMD lowering didn't take
effect yet?  Do we have to adjust debug temps as well there?

[Bug middle-end/100508] ICE with '-g -O3': in expand_debug_locations, at cfgexpand.c:5618

[marxin at gcc dot gnu.org]

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

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

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

--- Comment #2 from Martin Liška <marxin at gcc dot gnu.org> ---
Likely started with r6-4931-gfff7721799b3bf7c.

[Bug middle-end/100508] ICE with '-g -O3': in expand_debug_locations, at cfgexpand.c:5618

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
If you change it to #pragma omp declare simd it will start certainly earlier.
I think the bug is in the inliner.
Before dse1 we have:
  V m;

  <bb 2> :
  m_2 = j;
  # DEBUG m => m_2
and dse1 turns that into:
  # DEBUG D#1 => j
  # DEBUG m => D#1
But it seems the inliner doesn't remap the DEBUG_EXPR_DECLs, which means they
are shared between different functions, and during expansion the corresponding
DEBUG_EXPRs are shared between the functions too:
    case DEBUG_EXPR_DECL:
      op0 = DECL_RTL_IF_SET (exp);

      if (op0)
        return op0;

      op0 = gen_rtx_DEBUG_EXPR (mode);
      DEBUG_EXPR_TREE_DECL (op0) = exp;
      SET_DECL_RTL (exp, op0);

      return op0;
because DECL_RTL will be set after expanding first function referencing that.

So, I guess one option is to remap DEBUG_EXPR_DECLs during inlining (and
function versioning etc.), but guess that would need to be done very carefully
for the DW_OP_GNU_parameter_ref case of optimized away arguments, another one
would be to clear DECL_RTL of DEBUG_EXPR_DECLs at the end of expansion (say
push DEBUG_EXPR_DECLs for which we SET_DECL_RTL into a vector and then walk the
vector and clear DECL_RTLs), or do this only for the vector type mode mismatch
case (ignore DECL_RTL in that case and therefore force a different DEBUG_EXPR).

[Bug middle-end/100508] ICE with '-g -O3': in expand_debug_locations, at cfgexpand.c:5618

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 50788
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50788&action=edit
gcc12-pr100508.patch

Untested fix.

[Bug middle-end/100508] ICE with '-g -O3': in expand_debug_locations, at cfgexpand.c:5618

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:19040050aa2c8ee890fc58dda48639fc91bf0af0

commit r12-736-g19040050aa2c8ee890fc58dda48639fc91bf0af0
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Wed May 12 10:38:35 2021 +0200

    expand: Don't reuse DEBUG_EXPRs with vector type if they have different
modes [PR100508]

    The inliner doesn't remap DEBUG_EXPR_DECLs, so the same decls can appear
    in multiple functions.
    Furthermore, expansion reuses corresponding DEBUG_EXPRs too, so they again
    can be reused in multiple functions.
    Neither of that is a major problem, DEBUG_EXPRs are just magic value
holders
    and what value they stand for is independent in each function and driven by
    what debug stmts or DEBUG_INSNs they are bound to.
    Except for DEBUG_EXPR*s with vector types, TYPE_MODE can be either BLKmode
    or some vector mode depending on whether current function's enabled ISAs
    support that vector mode or not.  On the following testcase, we expand it
    first in foo function without AVX2 enabled and so the DEBUG_EXPR is
    BLKmode, but later the same DEBUG_EXPR_DECL is used in a simd clone with
    AVX2 enabled and expansion ICEs because of a mode mismatch.

    The following patch fixes that by forcing recreation of a DEBUG_EXPR if
    there is a mode mismatch for vector typed DEBUG_EXPR_DECL, DEBUG_EXPRs
    will be still reused in between functions otherwise and within the same
    function the mode should be always the same.

    2021-05-12  Jakub Jelinek  <jakub@redhat.com>

            PR middle-end/100508
            * cfgexpand.c (expand_debug_expr): For DEBUG_EXPR_DECL with vector
            type, don't reuse DECL_RTL if it has different mode, instead force
            creation of a new DEBUG_EXPR.

            * gcc.dg/gomp/pr100508.c: New test.

[Bug middle-end/100508] ICE with '-g -O3': in expand_debug_locations, at cfgexpand.c:5618

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:5998192bff6313a49d1e78bb224f8d7600a6072d

commit r11-8403-g5998192bff6313a49d1e78bb224f8d7600a6072d
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Wed May 12 10:38:35 2021 +0200

    expand: Don't reuse DEBUG_EXPRs with vector type if they have different
modes [PR100508]

    The inliner doesn't remap DEBUG_EXPR_DECLs, so the same decls can appear
    in multiple functions.
    Furthermore, expansion reuses corresponding DEBUG_EXPRs too, so they again
    can be reused in multiple functions.
    Neither of that is a major problem, DEBUG_EXPRs are just magic value
holders
    and what value they stand for is independent in each function and driven by
    what debug stmts or DEBUG_INSNs they are bound to.
    Except for DEBUG_EXPR*s with vector types, TYPE_MODE can be either BLKmode
    or some vector mode depending on whether current function's enabled ISAs
    support that vector mode or not.  On the following testcase, we expand it
    first in foo function without AVX2 enabled and so the DEBUG_EXPR is
    BLKmode, but later the same DEBUG_EXPR_DECL is used in a simd clone with
    AVX2 enabled and expansion ICEs because of a mode mismatch.

    The following patch fixes that by forcing recreation of a DEBUG_EXPR if
    there is a mode mismatch for vector typed DEBUG_EXPR_DECL, DEBUG_EXPRs
    will be still reused in between functions otherwise and within the same
    function the mode should be always the same.

    2021-05-12  Jakub Jelinek  <jakub@redhat.com>

            PR middle-end/100508
            * cfgexpand.c (expand_debug_expr): For DEBUG_EXPR_DECL with vector
            type, don't reuse DECL_RTL if it has different mode, instead force
            creation of a new DEBUG_EXPR.

            * gcc.dg/gomp/pr100508.c: New test.

    (cherry picked from commit 19040050aa2c8ee890fc58dda48639fc91bf0af0)

[Bug middle-end/100508] ICE with '-g -O3': in expand_debug_locations, at cfgexpand.c:5618

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed for 11.2/12+ so far.

[Bug middle-end/100508] ICE with '-g -O3': in expand_debug_locations, at cfgexpand.c:5618

[cvs-commit at gcc dot gnu.org]

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

--- Comment #8 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:c668e0cf83a74c5ec5b891b8b5c6a205dabc729a

commit r10-10609-gc668e0cf83a74c5ec5b891b8b5c6a205dabc729a
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Wed May 12 10:38:35 2021 +0200

    expand: Don't reuse DEBUG_EXPRs with vector type if they have different
modes [PR100508]

    The inliner doesn't remap DEBUG_EXPR_DECLs, so the same decls can appear
    in multiple functions.
    Furthermore, expansion reuses corresponding DEBUG_EXPRs too, so they again
    can be reused in multiple functions.
    Neither of that is a major problem, DEBUG_EXPRs are just magic value
holders
    and what value they stand for is independent in each function and driven by
    what debug stmts or DEBUG_INSNs they are bound to.
    Except for DEBUG_EXPR*s with vector types, TYPE_MODE can be either BLKmode
    or some vector mode depending on whether current function's enabled ISAs
    support that vector mode or not.  On the following testcase, we expand it
    first in foo function without AVX2 enabled and so the DEBUG_EXPR is
    BLKmode, but later the same DEBUG_EXPR_DECL is used in a simd clone with
    AVX2 enabled and expansion ICEs because of a mode mismatch.

    The following patch fixes that by forcing recreation of a DEBUG_EXPR if
    there is a mode mismatch for vector typed DEBUG_EXPR_DECL, DEBUG_EXPRs
    will be still reused in between functions otherwise and within the same
    function the mode should be always the same.

    2021-05-12  Jakub Jelinek  <jakub@redhat.com>

            PR middle-end/100508
            * cfgexpand.c (expand_debug_expr): For DEBUG_EXPR_DECL with vector
            type, don't reuse DECL_RTL if it has different mode, instead force
            creation of a new DEBUG_EXPR.

            * gcc.dg/gomp/pr100508.c: New test.

    (cherry picked from commit 19040050aa2c8ee890fc58dda48639fc91bf0af0)

[Bug middle-end/100508] ICE with '-g -O3': in expand_debug_locations, at cfgexpand.c:5618

[cvs-commit at gcc dot gnu.org]

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

--- Comment #9 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:ba374dfb937a8ac1c7c4740913331951a924f88b

commit r9-10071-gba374dfb937a8ac1c7c4740913331951a924f88b
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Wed May 12 10:38:35 2021 +0200

    expand: Don't reuse DEBUG_EXPRs with vector type if they have different
modes [PR100508]

    The inliner doesn't remap DEBUG_EXPR_DECLs, so the same decls can appear
    in multiple functions.
    Furthermore, expansion reuses corresponding DEBUG_EXPRs too, so they again
    can be reused in multiple functions.
    Neither of that is a major problem, DEBUG_EXPRs are just magic value
holders
    and what value they stand for is independent in each function and driven by
    what debug stmts or DEBUG_INSNs they are bound to.
    Except for DEBUG_EXPR*s with vector types, TYPE_MODE can be either BLKmode
    or some vector mode depending on whether current function's enabled ISAs
    support that vector mode or not.  On the following testcase, we expand it
    first in foo function without AVX2 enabled and so the DEBUG_EXPR is
    BLKmode, but later the same DEBUG_EXPR_DECL is used in a simd clone with
    AVX2 enabled and expansion ICEs because of a mode mismatch.

    The following patch fixes that by forcing recreation of a DEBUG_EXPR if
    there is a mode mismatch for vector typed DEBUG_EXPR_DECL, DEBUG_EXPRs
    will be still reused in between functions otherwise and within the same
    function the mode should be always the same.

    2021-05-12  Jakub Jelinek  <jakub@redhat.com>

            PR middle-end/100508
            * cfgexpand.c (expand_debug_expr): For DEBUG_EXPR_DECL with vector
            type, don't reuse DECL_RTL if it has different mode, instead force
            creation of a new DEBUG_EXPR.

            * gcc.dg/gomp/pr100508.c: New test.

    (cherry picked from commit 19040050aa2c8ee890fc58dda48639fc91bf0af0)

[Bug middle-end/100508] ICE with '-g -O3': in expand_debug_locations, at cfgexpand.c:5618

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed.