[Bug sanitizer/105093] New: ICE in expand_expr_addr_expr_1, at expr.c:7607 since r6-3529-gf11a7b6d57f6fcba

[Bug sanitizer/105093] New: ICE in expand_expr_addr_expr_1, at expr.c:7607 since r6-3529-gf11a7b6d57f6fcba

[marxin at gcc dot gnu.org]

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

            Bug ID: 105093
           Summary: ICE in expand_expr_addr_expr_1, at expr.c:7607 since
                    r6-3529-gf11a7b6d57f6fcba
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: sanitizer
          Assignee: unassigned at gcc dot gnu.org
          Reporter: marxin at gcc dot gnu.org
                CC: aoliva at gcc dot gnu.org, dodji at gcc dot gnu.org,
                    dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org,
                    kcc at gcc dot gnu.org, marxin at gcc dot gnu.org
  Target Milestone: ---

The following crashes:

$ cat nrvo.cpp
struct X {
  X();
  ~X();
};
volatile X test21() {
  X x;
  return x;
}

$ g++ nrvo.cpp -c -O2 -fsanitize=undefined -c
during RTL pass: expand
nrvo.cpp: In function ‘volatile X test21()’:
nrvo.cpp:5:12: internal compiler error: in expand_expr_addr_expr_1, at
expr.cc:8435
    5 | volatile X test21() {
      |            ^~~~~~
0x7ea241 expand_expr_addr_expr_1
        /home/marxin/Programming/gcc/gcc/expr.cc:8435
0xe95b46 expand_expr_addr_expr
        /home/marxin/Programming/gcc/gcc/expr.cc:8548
0xe95b46 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
        /home/marxin/Programming/gcc/gcc/expr.cc:11767
0xe927fc expand_expr
        /home/marxin/Programming/gcc/gcc/expr.h:301
0xe927fc expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
        /home/marxin/Programming/gcc/gcc/expr.cc:9057
0xe96da6 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
        /home/marxin/Programming/gcc/gcc/expr.cc:10504
0xe99414 expand_expr
        /home/marxin/Programming/gcc/gcc/expr.h:301
0xe99414 expand_operands(tree_node*, tree_node*, rtx_def*, rtx_def**,
rtx_def**, expand_modifier)
        /home/marxin/Programming/gcc/gcc/expr.cc:8314
0xe8fb82 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
        /home/marxin/Programming/gcc/gcc/expr.cc:9281
0xe96da6 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
        /home/marxin/Programming/gcc/gcc/expr.cc:10504
0xe99414 expand_expr
        /home/marxin/Programming/gcc/gcc/expr.h:301
0xe99414 expand_operands(tree_node*, tree_node*, rtx_def*, rtx_def**,
rtx_def**, expand_modifier)
        /home/marxin/Programming/gcc/gcc/expr.cc:8314
0xe8f8b2 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
        /home/marxin/Programming/gcc/gcc/expr.cc:10295
0xd626c5 expand_gimple_stmt_1
        /home/marxin/Programming/gcc/gcc/cfgexpand.cc:3972
0xd626c5 expand_gimple_stmt
        /home/marxin/Programming/gcc/gcc/cfgexpand.cc:4033
0xd684f4 expand_gimple_basic_block
        /home/marxin/Programming/gcc/gcc/cfgexpand.cc:6080
0xd6a6c7 execute
        /home/marxin/Programming/gcc/gcc/cfgexpand.cc:6806
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

[Bug sanitizer/105093] ICE in expand_expr_addr_expr_1, at expr.c:7607 since r6-3529-gf11a7b6d57f6fcba

[marxin at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2022-03-29
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

[Bug sanitizer/105093] ICE in expand_expr_addr_expr_1, at expr.c:7607 since r6-3529-gf11a7b6d57f6fcba

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
--- t.ii.025t.waccess1  2022-03-29 12:27:14.769503716 +0200
+++ t.ii.026t.ubsan     2022-03-29 12:27:14.769503716 +0200
...
 volatile struct X test21 ()
 {
   volatile struct X & x.0_1;
   volatile struct X & x.1_2;
+  unsigned long _5;
+  unsigned long _6;
+  sizetype _7;
+  sizetype _8;

   <bb 2> :
+  _5 = (unsigned long) &<retval>;
+  _6 = (unsigned long) &<retval>;
+  _7 = _5 - _6;
+  _8 = _7 + 8;
+  .UBSAN_OBJECT_SIZE (&<retval>, _8, 8, 0);
   x.0_1 ={v} <retval>;
   X::X (x.0_1);
   return <retval>;

the ubsan pass fails to mark <retval> as TREE_ADDRESSABLE.

[Bug sanitizer/105093] ICE in expand_expr_addr_expr_1, at expr.c:7607 since r6-3529-gf11a7b6d57f6fcba

[jakub at gcc dot gnu.org]

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

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 #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 52710
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52710&action=edit
gcc12-pr105093.patch

Untested fix.

[Bug sanitizer/105093] ICE in expand_expr_addr_expr_1, at expr.c:7607 since r6-3529-gf11a7b6d57f6fcba

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 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:e3e68fa59ead502c24950298b53c637bbe535a74

commit r12-7917-ge3e68fa59ead502c24950298b53c637bbe535a74
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Wed Mar 30 10:49:47 2022 +0200

    ubsan: Fix ICE due to -fsanitize=object-size [PR105093]

    The following testcase ICEs, because for a volatile X & RESULT_DECL
    ubsan wants to take address of that reference.  instrument_object_size
    is called with x, so the base is equal to the access and the var
    is automatic, so there is no risk of an out of bounds access for it.
    Normally we wouldn't instrument those because we fold address of the
    t - address of inner to 0, add constant size of the decl and it is
    equal to what __builtin_object_size computes.  But the volatile
    results in the subtraction not being folded.

    The first hunk fixes it by punting if we access the whole automatic
    decl, so that even volatile won't cause a problem.
    The second hunk (not strictly needed for this testcase) is similar
    to what has been added to asan.cc recently, if we actually take
    address of a decl and keep it in the IL, we better mark it addressable.

    2022-03-30  Jakub Jelinek  <jakub@redhat.com>

            PR sanitizer/105093
            * ubsan.cc (instrument_object_size): If t is equal to inner and
            is a decl other than global var, punt.  When emitting call to
            UBSAN_OBJECT_SIZE ifn, make sure base is addressable.

            * g++.dg/ubsan/pr105093.C: New test.

[Bug sanitizer/105093] ICE in expand_expr_addr_expr_1, at expr.c:7607 since r6-3529-gf11a7b6d57f6fcba

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 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:76a8ab576dbbe14b5a11e9feb454c3ca2f9b7e97

commit r11-9741-g76a8ab576dbbe14b5a11e9feb454c3ca2f9b7e97
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Wed Mar 30 10:49:47 2022 +0200

    ubsan: Fix ICE due to -fsanitize=object-size [PR105093]

    The following testcase ICEs, because for a volatile X & RESULT_DECL
    ubsan wants to take address of that reference.  instrument_object_size
    is called with x, so the base is equal to the access and the var
    is automatic, so there is no risk of an out of bounds access for it.
    Normally we wouldn't instrument those because we fold address of the
    t - address of inner to 0, add constant size of the decl and it is
    equal to what __builtin_object_size computes.  But the volatile
    results in the subtraction not being folded.

    The first hunk fixes it by punting if we access the whole automatic
    decl, so that even volatile won't cause a problem.
    The second hunk (not strictly needed for this testcase) is similar
    to what has been added to asan.cc recently, if we actually take
    address of a decl and keep it in the IL, we better mark it addressable.

    2022-03-30  Jakub Jelinek  <jakub@redhat.com>

            PR sanitizer/105093
            * ubsan.c (instrument_object_size): If t is equal to inner and
            is a decl other than global var, punt.  When emitting call to
            UBSAN_OBJECT_SIZE ifn, make sure base is addressable.

            * g++.dg/ubsan/pr105093.C: New test.

    (cherry picked from commit e3e68fa59ead502c24950298b53c637bbe535a74)

[Bug sanitizer/105093] [9/10 Regression] ICE in expand_expr_addr_expr_1, at expr.c:7607 since r6-3529-gf11a7b6d57f6fcba

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |9.5
            Summary|ICE in                      |[9/10 Regression] ICE in
                   |expand_expr_addr_expr_1, at |expand_expr_addr_expr_1, at
                   |expr.c:7607 since           |expr.c:7607 since
                   |r6-3529-gf11a7b6d57f6fcba   |r6-3529-gf11a7b6d57f6fcba
           Priority|P3                          |P2

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed for 11.3+ and 12.1+.

[Bug sanitizer/105093] [9/10 Regression] ICE in expand_expr_addr_expr_1, at expr.c:7607 since r6-3529-gf11a7b6d57f6fcba

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 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:2197da65c938e5f5dd7feb6c4c9be02f0b981275

commit r10-10702-g2197da65c938e5f5dd7feb6c4c9be02f0b981275
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Wed Mar 30 10:49:47 2022 +0200

    ubsan: Fix ICE due to -fsanitize=object-size [PR105093]

    The following testcase ICEs, because for a volatile X & RESULT_DECL
    ubsan wants to take address of that reference.  instrument_object_size
    is called with x, so the base is equal to the access and the var
    is automatic, so there is no risk of an out of bounds access for it.
    Normally we wouldn't instrument those because we fold address of the
    t - address of inner to 0, add constant size of the decl and it is
    equal to what __builtin_object_size computes.  But the volatile
    results in the subtraction not being folded.

    The first hunk fixes it by punting if we access the whole automatic
    decl, so that even volatile won't cause a problem.
    The second hunk (not strictly needed for this testcase) is similar
    to what has been added to asan.cc recently, if we actually take
    address of a decl and keep it in the IL, we better mark it addressable.

    2022-03-30  Jakub Jelinek  <jakub@redhat.com>

            PR sanitizer/105093
            * ubsan.c (instrument_object_size): If t is equal to inner and
            is a decl other than global var, punt.  When emitting call to
            UBSAN_OBJECT_SIZE ifn, make sure base is addressable.

            * g++.dg/ubsan/pr105093.C: New test.

    (cherry picked from commit e3e68fa59ead502c24950298b53c637bbe535a74)

[Bug sanitizer/105093] [9/10 Regression] ICE in expand_expr_addr_expr_1, at expr.c:7607 since r6-3529-gf11a7b6d57f6fcba

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 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:bee22b8bc1974773ec2d0e8bf64ad4fbba738fe4

commit r9-10143-gbee22b8bc1974773ec2d0e8bf64ad4fbba738fe4
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Wed Mar 30 10:49:47 2022 +0200

    ubsan: Fix ICE due to -fsanitize=object-size [PR105093]

    The following testcase ICEs, because for a volatile X & RESULT_DECL
    ubsan wants to take address of that reference.  instrument_object_size
    is called with x, so the base is equal to the access and the var
    is automatic, so there is no risk of an out of bounds access for it.
    Normally we wouldn't instrument those because we fold address of the
    t - address of inner to 0, add constant size of the decl and it is
    equal to what __builtin_object_size computes.  But the volatile
    results in the subtraction not being folded.

    The first hunk fixes it by punting if we access the whole automatic
    decl, so that even volatile won't cause a problem.
    The second hunk (not strictly needed for this testcase) is similar
    to what has been added to asan.cc recently, if we actually take
    address of a decl and keep it in the IL, we better mark it addressable.

    2022-03-30  Jakub Jelinek  <jakub@redhat.com>

            PR sanitizer/105093
            * ubsan.c (instrument_object_size): If t is equal to inner and
            is a decl other than global var, punt.  When emitting call to
            UBSAN_OBJECT_SIZE ifn, make sure base is addressable.

            * g++.dg/ubsan/pr105093.C: New test.

    (cherry picked from commit e3e68fa59ead502c24950298b53c637bbe535a74)

[Bug sanitizer/105093] [9/10 Regression] ICE in expand_expr_addr_expr_1, at expr.c:7607 since r6-3529-gf11a7b6d57f6fcba

[jakub at gcc dot gnu.org]

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

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

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

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