[Bug c++/99033] New: [11 Regression] ICE in tree_to_poly_int64, at tree.c:3091

[Bug c++/99033] New: [11 Regression] ICE in tree_to_poly_int64, at tree.c:3091

[gscfq@t-online.de]

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

            Bug ID: 99033
           Summary: [11 Regression] ICE in tree_to_poly_int64, at
                    tree.c:3091
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: gscfq@t-online.de
  Target Milestone: ---

Behavior of release versions changed between 20200517 and 20200524 :


$ cat z1.cc
struct S {
  char c;
  struct T {} T::*b[];
} a;

void f ()
{
  a.c = 1;
}


$ g++-11-20200517 -c z1.cc -fsanitize=undefined
$
$ g++-11-20210207 -c z1.cc -fsanitize=undefined
during GIMPLE pass: ubsan
z1.cc: In function 'void f()':
z1.cc:9:1: internal compiler error: in tree_to_poly_int64, at tree.c:3091
    9 | }
      | ^
0xf4bbe8 tree_to_poly_int64(tree_node const*)
        ../../gcc/tree.c:3091
0xf68db4 component_ref_size(tree_node*, special_array_member*)
        ../../gcc/tree.c:13909
0xd6eb12 decl_init_size(tree_node*, bool)
        ../../gcc/tree-object-size.c:196
0xd6f062 addr_object_size
        ../../gcc/tree-object-size.c:285
0xd70583 compute_builtin_object_size(tree_node*, int, unsigned long*,
tree_node**, tree_node**)
        ../../gcc/tree-object-size.c:570
0xcf945a instrument_object_size
        ../../gcc/ubsan.c:2150
0xcfe535 execute
        ../../gcc/ubsan.c:2405

[Bug c++/99033] [11 Regression] ICE in tree_to_poly_int64, at tree.c:3091

[gscfq@t-online.de]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |x86_64-pc-linux-gnu
           Keywords|                            |ice-on-valid-code

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

Seems to go back to r6 when configured with --enable-checking=yes :
(and then with no need for -fsanitize=undefined)


$ g++-11-20210207 -c z1.cc
z1.cc:9:1: internal compiler error: tree check: expected constructor, have
error_mark in array_size_for_constructor, at varasm.c:5340
    9 | }
      | ^
0x6629b8 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
        ../../gcc/tree.c:9814
0x1389b07 tree_check(tree_node*, char const*, int, char const*, tree_code)
        ../../gcc/tree.h:3349
0x1389b07 array_size_for_constructor
        ../../gcc/varasm.c:5340
0x1389b07 output_constructor_regular_field
        ../../gcc/varasm.c:5511
0x1389b07 output_constructor
        ../../gcc/varasm.c:5797
0x1389ee9 output_constant
        ../../gcc/varasm.c:5149
#...

[Bug c++/99033] [9/10/11 Regression] ICE in tree_to_poly_int64, at tree.c:3091

[mpolacek at gcc dot gnu.org]

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

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mpolacek at gcc dot gnu.org
            Summary|[11 Regression] ICE in      |[9/10/11 Regression] ICE in
                   |tree_to_poly_int64, at      |tree_to_poly_int64, at
                   |tree.c:3091                 |tree.c:3091
   Target Milestone|---                         |9.4
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2021-02-09

--- Comment #2 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Seems to have started with r231665.

[Bug c++/99033] [9/10/11 Regression] ICE in tree_to_poly_int64, at tree.c:3091

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2

[Bug c++/99033] [9/10/11 Regression] ICE in tree_to_poly_int64, at tree.c:3091

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 50163
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50163&action=edit
gcc11-pr99033.patch

Untested fix.

[Bug c++/99033] [9/10/11 Regression] ICE in tree_to_poly_int64, at tree.c:3091

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 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:2dcdd15d0bafb9b45a8d7ff580217bd6ac1f0975

commit r11-7193-g2dcdd15d0bafb9b45a8d7ff580217bd6ac1f0975
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Thu Feb 11 17:24:17 2021 +0100

    c++: Fix zero initialization of flexible array members [PR99033]

    array_type_nelts returns error_mark_node for type of flexible array members
    and build_zero_init_1 was placing an error_mark_node into the CONSTRUCTOR,
    on which e.g. varasm ICEs.  I think there is nothing erroneous on zero
    initialization of flexible array members though, such arrays should simply
    get no elements, like they do if such classes are constructed (everything
    except when some larger initializer comes from an explicit initializer).

    So, this patch handles [] arrays in zero initialization like [0] arrays
    and fixes handling of the [0] arrays - the
    tree_int_cst_equal (max_index, integer_minus_one_node) check
    didn't do what it thought it would do, max_index is typically unsigned
    integer (sizetype) and so it is never equal to a -1.

    What the patch doesn't do and maybe would be desirable is if it returns
    error_mark_node for other reasons let the recursive callers not stick that
    into CONSTRUCTOR but return error_mark_node instead.  But I don't have a
    testcase where that would be needed right now.

    2021-02-11  Jakub Jelinek  <jakub@redhat.com>

            PR c++/99033
            * init.c (build_zero_init_1): Handle zero initialiation of
            flexible array members like initialization of [0] arrays.
            Use integer_minus_onep instead of comparison to
integer_minus_one_node
            and integer_zerop instead of comparison against size_zero_node.
            Formatting fixes.

            * g++.dg/ext/flexary38.C: New test.

[Bug c++/99033] [9/10 Regression] ICE in tree_to_poly_int64, at tree.c:3091

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[9/10/11 Regression] ICE in |[9/10 Regression] ICE in
                   |tree_to_poly_int64, at      |tree_to_poly_int64, at
                   |tree.c:3091                 |tree.c:3091

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed on the trunk so far.

[Bug c++/99033] [9/10 Regression] ICE in tree_to_poly_int64, at tree.c:3091

[cvs-commit at gcc dot gnu.org]

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

--- 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:ea535f59b19f65e5b313c990ee6c194a7b055bd7

commit r10-9468-gea535f59b19f65e5b313c990ee6c194a7b055bd7
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Thu Feb 11 17:24:17 2021 +0100

    c++: Fix zero initialization of flexible array members [PR99033]

    array_type_nelts returns error_mark_node for type of flexible array members
    and build_zero_init_1 was placing an error_mark_node into the CONSTRUCTOR,
    on which e.g. varasm ICEs.  I think there is nothing erroneous on zero
    initialization of flexible array members though, such arrays should simply
    get no elements, like they do if such classes are constructed (everything
    except when some larger initializer comes from an explicit initializer).

    So, this patch handles [] arrays in zero initialization like [0] arrays
    and fixes handling of the [0] arrays - the
    tree_int_cst_equal (max_index, integer_minus_one_node) check
    didn't do what it thought it would do, max_index is typically unsigned
    integer (sizetype) and so it is never equal to a -1.

    What the patch doesn't do and maybe would be desirable is if it returns
    error_mark_node for other reasons let the recursive callers not stick that
    into CONSTRUCTOR but return error_mark_node instead.  But I don't have a
    testcase where that would be needed right now.

    2021-02-11  Jakub Jelinek  <jakub@redhat.com>

            PR c++/99033
            * init.c (build_zero_init_1): Handle zero initialiation of
            flexible array members like initialization of [0] arrays.
            Use integer_minus_onep instead of comparison to
integer_minus_one_node
            and integer_zerop instead of comparison against size_zero_node.
            Formatting fixes.

            * g++.dg/ext/flexary38.C: New test.

    (cherry picked from commit 2dcdd15d0bafb9b45a8d7ff580217bd6ac1f0975)

[Bug c++/99033] [9 Regression] ICE in tree_to_poly_int64, at tree.c:3091

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[9/10 Regression] ICE in    |[9 Regression] ICE in
                   |tree_to_poly_int64, at      |tree_to_poly_int64, at
                   |tree.c:3091                 |tree.c:3091

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed for 10.3 too.

[Bug c++/99033] [9 Regression] ICE in tree_to_poly_int64, at tree.c:3091

[cvs-commit at gcc dot gnu.org]

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

--- Comment #8 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:d1eaf74ee3ac503576e2830e77505cce1ee56e8d

commit r9-9419-gd1eaf74ee3ac503576e2830e77505cce1ee56e8d
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Thu Feb 11 17:24:17 2021 +0100

    c++: Fix zero initialization of flexible array members [PR99033]

    array_type_nelts returns error_mark_node for type of flexible array members
    and build_zero_init_1 was placing an error_mark_node into the CONSTRUCTOR,
    on which e.g. varasm ICEs.  I think there is nothing erroneous on zero
    initialization of flexible array members though, such arrays should simply
    get no elements, like they do if such classes are constructed (everything
    except when some larger initializer comes from an explicit initializer).

    So, this patch handles [] arrays in zero initialization like [0] arrays
    and fixes handling of the [0] arrays - the
    tree_int_cst_equal (max_index, integer_minus_one_node) check
    didn't do what it thought it would do, max_index is typically unsigned
    integer (sizetype) and so it is never equal to a -1.

    What the patch doesn't do and maybe would be desirable is if it returns
    error_mark_node for other reasons let the recursive callers not stick that
    into CONSTRUCTOR but return error_mark_node instead.  But I don't have a
    testcase where that would be needed right now.

    2021-02-11  Jakub Jelinek  <jakub@redhat.com>

            PR c++/99033
            * init.c (build_zero_init_1): Handle zero initialiation of
            flexible array members like initialization of [0] arrays.
            Use integer_minus_onep instead of comparison to
integer_minus_one_node
            and integer_zerop instead of comparison against size_zero_node.
            Formatting fixes.

            * g++.dg/ext/flexary38.C: New test.

    (cherry picked from commit ea535f59b19f65e5b313c990ee6c194a7b055bd7)

[Bug c++/99033] [9 Regression] ICE in tree_to_poly_int64, at tree.c:3091

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:5e677eeab4d37ae9c19e24a56a899f1f05d01280

commit r8-10884-g5e677eeab4d37ae9c19e24a56a899f1f05d01280
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Thu Feb 11 17:24:17 2021 +0100

    c++: Fix zero initialization of flexible array members [PR99033]

    array_type_nelts returns error_mark_node for type of flexible array members
    and build_zero_init_1 was placing an error_mark_node into the CONSTRUCTOR,
    on which e.g. varasm ICEs.  I think there is nothing erroneous on zero
    initialization of flexible array members though, such arrays should simply
    get no elements, like they do if such classes are constructed (everything
    except when some larger initializer comes from an explicit initializer).

    So, this patch handles [] arrays in zero initialization like [0] arrays
    and fixes handling of the [0] arrays - the
    tree_int_cst_equal (max_index, integer_minus_one_node) check
    didn't do what it thought it would do, max_index is typically unsigned
    integer (sizetype) and so it is never equal to a -1.

    What the patch doesn't do and maybe would be desirable is if it returns
    error_mark_node for other reasons let the recursive callers not stick that
    into CONSTRUCTOR but return error_mark_node instead.  But I don't have a
    testcase where that would be needed right now.

    2021-02-11  Jakub Jelinek  <jakub@redhat.com>

            PR c++/99033
            * init.c (build_zero_init_1): Handle zero initialiation of
            flexible array members like initialization of [0] arrays.
            Use integer_minus_onep instead of comparison to
integer_minus_one_node
            and integer_zerop instead of comparison against size_zero_node.
            Formatting fixes.

            * g++.dg/ext/flexary38.C: New test.

    (cherry picked from commit ea535f59b19f65e5b313c990ee6c194a7b055bd7)

[Bug c++/99033] [9 Regression] ICE in tree_to_poly_int64, at tree.c:3091

[jakub at gcc dot gnu.org]

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

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

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

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