]> git.ipfire.org Git - thirdparty/gcc.git/commit - gcc/cp/init.cc
c++: Fix zero initialization of flexible array members [PR99033]
authorJakub Jelinek <jakub@redhat.com>
Thu, 11 Feb 2021 16:24:17 +0000 (17:24 +0100)
committerJakub Jelinek <jakub@redhat.com>
Thu, 11 Feb 2021 16:24:17 +0000 (17:24 +0100)
commit2dcdd15d0bafb9b45a8d7ff580217bd6ac1f0975
tree35b82277e29a2ab59f06f5844d580301fc360e78
parentf0da1c0cb7661ee9111bc475efddae80a026de34
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.
gcc/cp/init.c
gcc/testsuite/g++.dg/ext/flexary38.C [new file with mode: 0644]