Re: [PATCH] don't trim empty string initializers for pointers (PR 90947)
On Thu, Aug 1, 2019, 6:01 PM Martin Sebor wrote:
> On 8/1/19 3:09 PM, Jason Merrill wrote:
> > On 8/1/19 4:22 PM, Martin Sebor wrote:
> >> On 6/27/19 3:25 PM, Jason Merrill wrote:
> >>> On 6/23/19 5:51 PM, Martin Sebor wrote:
> On 6/22/19 9:37 PM, Jason Merrill wrote:
> > On 6/21/19 8:05 PM, Martin Sebor wrote:
> >> The solution we implemented in GCC 9 to get the mangling of
> >> non-type template arguments of class types containing array
> >> members consistent regardless of the form of their
> >> initialization introduced a couple of bugs. One of these
> >> is the subject of this patch. The bug results in stripping
> >> trailing initializers for array elements that involve the empty
> >> string such as in here:
> >>
> >>void f (void)
> >>{
> >> const char* a[1][1] = { "" };
> >> if (!a[0][0])
> >>__builtin_abort ();
> >>}
> >>
> >> The problem is caused by relying on initializer_zerop() that
> >> returns true for the empty string regardless of whether it's
> >> used to initialize an array or a pointer (the function doesn't
> >> know what the initializer is being used for).
> >
> > Why doesn't the existing POINTER_TYPE_P check handle this? It's
> > clearly intended to.
>
> It does but only only for initializers of "leaf" elements/members.
> The function processes initializers of enclosing elements or members
> recursively. When initializer_zerop returns true for one of those,
> it doesn't differentiate between an empty string that's being used
> to initialize a leaf array or a leaf pointer.
>
> For the example above, the first time through, elt_type is char*
> and elt_init is the empty string, or the array char[1], and so
> the initializer is retained.
>
> The second time through (after the leaf recursive call returns),
> elt_init is { "" } (i.e., an array of one empty string), elt_type
> is also an array, and initializer_zerop(elt_init) returns true, so
> the initializer is dropped.
>
> I'm actually surprised this initializer_zerop ambiguity between
> arrays and strings doesn't come up elsewhere. That's also why
> I added the new function to tree.c.
> >>>
> >>> Makes sense.
> >>>
> Btw., it belatedly occurred to me that the new function doesn't
> correctly handled unnamed bit-fields so I've corrected it to
> handle those as well. Attached is the revised patch with this
> change and a test to exercise it.
> >>>
> + || (DECL_BIT_FIELD (fld) && !!DECL_NAME (fld)))
> >>>
> >>> Hmm, this looks like it would skip named bit-fields rather than
> unnamed.
> >>
> >> It was a typo that I fixed by hand separately in my tree and in
> >> the patch but missed Emacs' question when saving the patch and
> >> wound up sending the unchanged version.
> >>
> PS I found DECL_UNNAMED_BIT_FIELD in c-family/c-common.h.
> I used (DECL_BIT_FIELD (fld) && !DECL_NAME (fld)) because
> the former macro isn't available in tree.c. Does that mean
> that that would make the new function not completely correct
> in some other languages?
> >>>
> >>> I don't know if other languages treat unnamed bit-fields as
> >>> initializable.
> >>>
> +/* Analogous to initializer_zerop but examines the type for which
> + the initializer is being used but unlike it, considers empty
> + strings to be zero initializers for arrays and non-zero for
> + pointers. */
> >>>
> >>> This comment could use more editing.
> >>
> >> I've broken up the long sentence into two so it reads a little
> >> better. If you were objecting to something else please let me
> >> know.
> >>
> >> Other than that and the typo the patch is the same.
> >
> > OK, thanks.
>
> Just to be sure before I commit it: is this OK meant as an approval
> of the patch (as opposed to just an acknowledgment of the changes)?
>
Yes.
Jason
Re: [PATCH] don't trim empty string initializers for pointers (PR 90947)
On 8/1/19 3:09 PM, Jason Merrill wrote:
On 8/1/19 4:22 PM, Martin Sebor wrote:
On 6/27/19 3:25 PM, Jason Merrill wrote:
On 6/23/19 5:51 PM, Martin Sebor wrote:
On 6/22/19 9:37 PM, Jason Merrill wrote:
On 6/21/19 8:05 PM, Martin Sebor wrote:
The solution we implemented in GCC 9 to get the mangling of
non-type template arguments of class types containing array
members consistent regardless of the form of their
initialization introduced a couple of bugs. One of these
is the subject of this patch. The bug results in stripping
trailing initializers for array elements that involve the empty
string such as in here:
void f (void)
{
const char* a[1][1] = { "" };
if (!a[0][0])
__builtin_abort ();
}
The problem is caused by relying on initializer_zerop() that
returns true for the empty string regardless of whether it's
used to initialize an array or a pointer (the function doesn't
know what the initializer is being used for).
Why doesn't the existing POINTER_TYPE_P check handle this? It's
clearly intended to.
It does but only only for initializers of "leaf" elements/members.
The function processes initializers of enclosing elements or members
recursively. When initializer_zerop returns true for one of those,
it doesn't differentiate between an empty string that's being used
to initialize a leaf array or a leaf pointer.
For the example above, the first time through, elt_type is char*
and elt_init is the empty string, or the array char[1], and so
the initializer is retained.
The second time through (after the leaf recursive call returns),
elt_init is { "" } (i.e., an array of one empty string), elt_type
is also an array, and initializer_zerop(elt_init) returns true, so
the initializer is dropped.
I'm actually surprised this initializer_zerop ambiguity between
arrays and strings doesn't come up elsewhere. That's also why
I added the new function to tree.c.
Makes sense.
Btw., it belatedly occurred to me that the new function doesn't
correctly handled unnamed bit-fields so I've corrected it to
handle those as well. Attached is the revised patch with this
change and a test to exercise it.
+ || (DECL_BIT_FIELD (fld) && !!DECL_NAME (fld)))
Hmm, this looks like it would skip named bit-fields rather than unnamed.
It was a typo that I fixed by hand separately in my tree and in
the patch but missed Emacs' question when saving the patch and
wound up sending the unchanged version.
PS I found DECL_UNNAMED_BIT_FIELD in c-family/c-common.h.
I used (DECL_BIT_FIELD (fld) && !DECL_NAME (fld)) because
the former macro isn't available in tree.c. Does that mean
that that would make the new function not completely correct
in some other languages?
I don't know if other languages treat unnamed bit-fields as
initializable.
+/* Analogous to initializer_zerop but examines the type for which
+ the initializer is being used but unlike it, considers empty
+ strings to be zero initializers for arrays and non-zero for
+ pointers. */
This comment could use more editing.
I've broken up the long sentence into two so it reads a little
better. If you were objecting to something else please let me
know.
Other than that and the typo the patch is the same.
OK, thanks.
Just to be sure before I commit it: is this OK meant as an approval
of the patch (as opposed to just an acknowledgment of the changes)?
Thanks
Martin
Re: [PATCH] don't trim empty string initializers for pointers (PR 90947)
On 8/1/19 4:22 PM, Martin Sebor wrote:
On 6/27/19 3:25 PM, Jason Merrill wrote:
On 6/23/19 5:51 PM, Martin Sebor wrote:
On 6/22/19 9:37 PM, Jason Merrill wrote:
On 6/21/19 8:05 PM, Martin Sebor wrote:
The solution we implemented in GCC 9 to get the mangling of
non-type template arguments of class types containing array
members consistent regardless of the form of their
initialization introduced a couple of bugs. One of these
is the subject of this patch. The bug results in stripping
trailing initializers for array elements that involve the empty
string such as in here:
void f (void)
{
const char* a[1][1] = { "" };
if (!a[0][0])
__builtin_abort ();
}
The problem is caused by relying on initializer_zerop() that
returns true for the empty string regardless of whether it's
used to initialize an array or a pointer (the function doesn't
know what the initializer is being used for).
Why doesn't the existing POINTER_TYPE_P check handle this? It's
clearly intended to.
It does but only only for initializers of "leaf" elements/members.
The function processes initializers of enclosing elements or members
recursively. When initializer_zerop returns true for one of those,
it doesn't differentiate between an empty string that's being used
to initialize a leaf array or a leaf pointer.
For the example above, the first time through, elt_type is char*
and elt_init is the empty string, or the array char[1], and so
the initializer is retained.
The second time through (after the leaf recursive call returns),
elt_init is { "" } (i.e., an array of one empty string), elt_type
is also an array, and initializer_zerop(elt_init) returns true, so
the initializer is dropped.
I'm actually surprised this initializer_zerop ambiguity between
arrays and strings doesn't come up elsewhere. That's also why
I added the new function to tree.c.
Makes sense.
Btw., it belatedly occurred to me that the new function doesn't
correctly handled unnamed bit-fields so I've corrected it to
handle those as well. Attached is the revised patch with this
change and a test to exercise it.
+ || (DECL_BIT_FIELD (fld) && !!DECL_NAME (fld)))
Hmm, this looks like it would skip named bit-fields rather than unnamed.
It was a typo that I fixed by hand separately in my tree and in
the patch but missed Emacs' question when saving the patch and
wound up sending the unchanged version.
PS I found DECL_UNNAMED_BIT_FIELD in c-family/c-common.h.
I used (DECL_BIT_FIELD (fld) && !DECL_NAME (fld)) because
the former macro isn't available in tree.c. Does that mean
that that would make the new function not completely correct
in some other languages?
I don't know if other languages treat unnamed bit-fields as
initializable.
+/* Analogous to initializer_zerop but examines the type for which
+ the initializer is being used but unlike it, considers empty
+ strings to be zero initializers for arrays and non-zero for
+ pointers. */
This comment could use more editing.
I've broken up the long sentence into two so it reads a little
better. If you were objecting to something else please let me
know.
Other than that and the typo the patch is the same.
OK, thanks.
Jason
Re: [PATCH] don't trim empty string initializers for pointers (PR 90947)
On 6/27/19 3:25 PM, Jason Merrill wrote:
On 6/23/19 5:51 PM, Martin Sebor wrote:
On 6/22/19 9:37 PM, Jason Merrill wrote:
On 6/21/19 8:05 PM, Martin Sebor wrote:
The solution we implemented in GCC 9 to get the mangling of
non-type template arguments of class types containing array
members consistent regardless of the form of their
initialization introduced a couple of bugs. One of these
is the subject of this patch. The bug results in stripping
trailing initializers for array elements that involve the empty
string such as in here:
void f (void)
{
const char* a[1][1] = { "" };
if (!a[0][0])
__builtin_abort ();
}
The problem is caused by relying on initializer_zerop() that
returns true for the empty string regardless of whether it's
used to initialize an array or a pointer (the function doesn't
know what the initializer is being used for).
Why doesn't the existing POINTER_TYPE_P check handle this? It's
clearly intended to.
It does but only only for initializers of "leaf" elements/members.
The function processes initializers of enclosing elements or members
recursively. When initializer_zerop returns true for one of those,
it doesn't differentiate between an empty string that's being used
to initialize a leaf array or a leaf pointer.
For the example above, the first time through, elt_type is char*
and elt_init is the empty string, or the array char[1], and so
the initializer is retained.
The second time through (after the leaf recursive call returns),
elt_init is { "" } (i.e., an array of one empty string), elt_type
is also an array, and initializer_zerop(elt_init) returns true, so
the initializer is dropped.
I'm actually surprised this initializer_zerop ambiguity between
arrays and strings doesn't come up elsewhere. That's also why
I added the new function to tree.c.
Makes sense.
Btw., it belatedly occurred to me that the new function doesn't
correctly handled unnamed bit-fields so I've corrected it to
handle those as well. Attached is the revised patch with this
change and a test to exercise it.
+ || (DECL_BIT_FIELD (fld) && !!DECL_NAME (fld)))
Hmm, this looks like it would skip named bit-fields rather than unnamed.
It was a typo that I fixed by hand separately in my tree and in
the patch but missed Emacs' question when saving the patch and
wound up sending the unchanged version.
PS I found DECL_UNNAMED_BIT_FIELD in c-family/c-common.h.
I used (DECL_BIT_FIELD (fld) && !DECL_NAME (fld)) because
the former macro isn't available in tree.c. Does that mean
that that would make the new function not completely correct
in some other languages?
I don't know if other languages treat unnamed bit-fields as initializable.
+/* Analogous to initializer_zerop but examines the type for which
+ the initializer is being used but unlike it, considers empty
+ strings to be zero initializers for arrays and non-zero for
+ pointers. */
This comment could use more editing.
I've broken up the long sentence into two so it reads a little
better. If you were objecting to something else please let me
know.
Other than that and the typo the patch is the same.
Martin
PR c++/90947 - Simple lookup table of array of strings is miscompiled
gcc/cp/ChangeLog:
PR c++/90947
* decl.c (reshape_init_array_1): Avoid truncating initializer
lists containing string literals.
gcc/testsuite/ChangeLog:
PR c++/90947
* c-c++-common/array-1.c: New test.
* g++.dg/abi/mangle73.C: New test.
* g++.dg/cpp2a/nontype-class23.C: New test.
* g++.dg/init/array53.C: New test.
gcc/ChangeLog:
PR c++/90947
* tree.c (type_initializer_zero_p): Define.
* tree.h (type_initializer_zero_p): New function.
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index c8b9e3b8fb9..a1ab5ca8193 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -5899,8 +5899,9 @@ reshape_init_array_1 (tree elt_type, tree max_index, reshape_iter *d,
/* Pointers initialized to strings must be treated as non-zero
even if the string is empty. */
tree init_type = TREE_TYPE (elt_init);
- if ((POINTER_TYPE_P (elt_type) != POINTER_TYPE_P (init_type))
- || !initializer_zerop (elt_init))
+ if ((POINTER_TYPE_P (elt_type) != POINTER_TYPE_P (init_type)))
+ last_nonzero = index;
+ else if (!type_initializer_zero_p (elt_type, elt_init))
last_nonzero = index;
/* This can happen with an invalid initializer (c++/54501). */
diff --git a/gcc/testsuite/c-c++-common/array-1.c b/gcc/testsuite/c-c++-common/array-1.c
new file mode 100644
index 000..5de9ade4d43
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/array-1.c
@@ -0,0 +1,247 @@
+// PR c++/90947 - Simple lookup table of array of strings is miscompiled
+// { dg-do compile }
+// { dg-options "-O1 -fdump-tree-optimized" }
+
+#define assert(expr) ((expr) ? (void)0 : __builtin_abort ())
+
+void pr90947 (void)
+{
+ int vecsize = 4;
+ int index = 0;
+ static const char *a[4][4] =
+{
+ { ".x", ".y", ".z", ".w" },
+ {
Re: [PATCH] don't trim empty string initializers for pointers (PR 90947)
On 6/23/19 5:51 PM, Martin Sebor wrote:
On 6/22/19 9:37 PM, Jason Merrill wrote:
On 6/21/19 8:05 PM, Martin Sebor wrote:
The solution we implemented in GCC 9 to get the mangling of
non-type template arguments of class types containing array
members consistent regardless of the form of their
initialization introduced a couple of bugs. One of these
is the subject of this patch. The bug results in stripping
trailing initializers for array elements that involve the empty
string such as in here:
void f (void)
{
const char* a[1][1] = { "" };
if (!a[0][0])
__builtin_abort ();
}
The problem is caused by relying on initializer_zerop() that
returns true for the empty string regardless of whether it's
used to initialize an array or a pointer (the function doesn't
know what the initializer is being used for).
Why doesn't the existing POINTER_TYPE_P check handle this? It's
clearly intended to.
It does but only only for initializers of "leaf" elements/members.
The function processes initializers of enclosing elements or members
recursively. When initializer_zerop returns true for one of those,
it doesn't differentiate between an empty string that's being used
to initialize a leaf array or a leaf pointer.
For the example above, the first time through, elt_type is char*
and elt_init is the empty string, or the array char[1], and so
the initializer is retained.
The second time through (after the leaf recursive call returns),
elt_init is { "" } (i.e., an array of one empty string), elt_type
is also an array, and initializer_zerop(elt_init) returns true, so
the initializer is dropped.
I'm actually surprised this initializer_zerop ambiguity between
arrays and strings doesn't come up elsewhere. That's also why
I added the new function to tree.c.
Makes sense.
Btw., it belatedly occurred to me that the new function doesn't
correctly handled unnamed bit-fields so I've corrected it to
handle those as well. Attached is the revised patch with this
change and a test to exercise it.
+|| (DECL_BIT_FIELD (fld) && !!DECL_NAME (fld)))
Hmm, this looks like it would skip named bit-fields rather than unnamed.
PS I found DECL_UNNAMED_BIT_FIELD in c-family/c-common.h.
I used (DECL_BIT_FIELD (fld) && !DECL_NAME (fld)) because
the former macro isn't available in tree.c. Does that mean
that that would make the new function not completely correct
in some other languages?
I don't know if other languages treat unnamed bit-fields as initializable.
+/* Analogous to initializer_zerop but examines the type for which
+ the initializer is being used but unlike it, considers empty
+ strings to be zero initializers for arrays and non-zero for
+ pointers. */
This comment could use more editing.
Jason
Re: [PATCH] don't trim empty string initializers for pointers (PR 90947)
On 6/22/19 9:37 PM, Jason Merrill wrote:
On 6/21/19 8:05 PM, Martin Sebor wrote:
The solution we implemented in GCC 9 to get the mangling of
non-type template arguments of class types containing array
members consistent regardless of the form of their
initialization introduced a couple of bugs. One of these
is the subject of this patch. The bug results in stripping
trailing initializers for array elements that involve the empty
string such as in here:
void f (void)
{
const char* a[1][1] = { "" };
if (!a[0][0])
__builtin_abort ();
}
The problem is caused by relying on initializer_zerop() that
returns true for the empty string regardless of whether it's
used to initialize an array or a pointer (the function doesn't
know what the initializer is being used for).
Why doesn't the existing POINTER_TYPE_P check handle this? It's clearly
intended to.
It does but only only for initializers of "leaf" elements/members.
The function processes initializers of enclosing elements or members
recursively. When initializer_zerop returns true for one of those,
it doesn't differentiate between an empty string that's being used
to initialize a leaf array or a leaf pointer.
For the example above, the first time through, elt_type is char*
and elt_init is the empty string, or the array char[1], and so
the initializer is retained.
The second time through (after the leaf recursive call returns),
elt_init is { "" } (i.e., an array of one empty string), elt_type
is also an array, and initializer_zerop(elt_init) returns true, so
the initializer is dropped.
I'm actually surprised this initializer_zerop ambiguity between
arrays and strings doesn't come up elsewhere. That's also why
I added the new function to tree.c.
Btw., it belatedly occurred to me that the new function doesn't
correctly handled unnamed bit-fields so I've corrected it to
handle those as well. Attached is the revised patch with this
change and a test to exercise it.
Martin
PS I found DECL_UNNAMED_BIT_FIELD in c-family/c-common.h.
I used (DECL_BIT_FIELD (fld) && !DECL_NAME (fld)) because
the former macro isn't available in tree.c. Does that mean
that that would make the new function not completely correct
in some other languages?
PR c++/90947 - Simple lookup table of array of strings is miscompiled
gcc/cp/ChangeLog:
PR c++/90947
* decl.c (reshape_init_array_1): Avoid truncating initializer
lists containing string literals.
gcc/testsuite/ChangeLog:
PR c++/90947
* c-c++-common/array-1.c: New test.
* g++.dg/abi/mangle73.C: New test.
* g++.dg/cpp2a/nontype-class18.C: New test.
* g++.dg/init/array53.C: New test.
gcc/ChangeLog:
PR c++/90947
* tree.c (type_initializer_zero_p): Define.
* tree.h (type_initializer_zero_p): New function.
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 98b54d542a0..95893631992 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -5863,8 +5863,9 @@ reshape_init_array_1 (tree elt_type, tree max_index, reshape_iter *d,
/* Pointers initialized to strings must be treated as non-zero
even if the string is empty. */
tree init_type = TREE_TYPE (elt_init);
- if ((POINTER_TYPE_P (elt_type) != POINTER_TYPE_P (init_type))
- || !initializer_zerop (elt_init))
+ if ((POINTER_TYPE_P (elt_type) != POINTER_TYPE_P (init_type)))
+ last_nonzero = index;
+ else if (!type_initializer_zero_p (elt_type, elt_init))
last_nonzero = index;
/* This can happen with an invalid initializer (c++/54501). */
diff --git a/gcc/testsuite/c-c++-common/array-1.c b/gcc/testsuite/c-c++-common/array-1.c
new file mode 100644
index 000..5de9ade4d43
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/array-1.c
@@ -0,0 +1,247 @@
+// PR c++/90947 - Simple lookup table of array of strings is miscompiled
+// { dg-do compile }
+// { dg-options "-O1 -fdump-tree-optimized" }
+
+#define assert(expr) ((expr) ? (void)0 : __builtin_abort ())
+
+void pr90947 (void)
+{
+ int vecsize = 4;
+ int index = 0;
+ static const char *a[4][4] =
+{
+ { ".x", ".y", ".z", ".w" },
+ { ".xy", ".yz", ".zw", 0 },
+ { ".xyz", ".yzw", 0, 0 },
+ { "", 0, 0, 0 },
+};
+
+ assert (vecsize >= 1 && vecsize <= 4);
+ assert (index >= 0 && index < 4);
+ assert (a[vecsize - 1][index]);
+}
+
+void f_a1_1 (void)
+{
+ {
+const char* a[1][1] = { { 0 } };
+assert (0 == a[0][0]);
+ }
+ {
+const char* a[1][1] = { { "" } };
+assert ('\0' == *a[0][0]);
+ }
+}
+
+void f_a2_1 (void)
+{
+ {
+const char* a[2][1] = { { "" }, { "" } };
+assert ('\0' == *a[0][0] && '\0' == *a[1][0]);
+ }
+ {
+const char* a[2][1] = { { 0 }, { "" } };
+assert (0 == a[0][0] && '\0' == *a[1][0]);
+ }
+ {
+const char* a[2][1] = { { }, { "" } };
+assert (0 == a[0][0] && '\0' == *a[1][0]);
+ }
+}
+
+void f_a2_2 (void)
+{
+ {
+const char* a[2][2] = { { "", "" }, { "", "" } };
+assert ('\0' == *a[0][0] && '\0' == *a[0][1]);
+assert ('\0' == *a[1][0] && '\0' == *a[1][1]);
+
Re: [PATCH] don't trim empty string initializers for pointers (PR 90947)
On 6/21/19 8:05 PM, Martin Sebor wrote:
The solution we implemented in GCC 9 to get the mangling of
non-type template arguments of class types containing array
members consistent regardless of the form of their
initialization introduced a couple of bugs. One of these
is the subject of this patch. The bug results in stripping
trailing initializers for array elements that involve the empty
string such as in here:
void f (void)
{
const char* a[1][1] = { "" };
if (!a[0][0])
__builtin_abort ();
}
The problem is caused by relying on initializer_zerop() that
returns true for the empty string regardless of whether it's
used to initialize an array or a pointer (the function doesn't
know what the initializer is being used for).
Why doesn't the existing POINTER_TYPE_P check handle this? It's clearly
intended to.
Jason
[PATCH] don't trim empty string initializers for pointers (PR 90947)
The solution we implemented in GCC 9 to get the mangling of
non-type template arguments of class types containing array
members consistent regardless of the form of their
initialization introduced a couple of bugs. One of these
is the subject of this patch. The bug results in stripping
trailing initializers for array elements that involve the empty
string such as in here:
void f (void)
{
const char* a[1][1] = { "" };
if (!a[0][0])
__builtin_abort ();
}
The problem is caused by relying on initializer_zerop() that
returns true for the empty string regardless of whether it's
used to initialize an array or a pointer (the function doesn't
know what the initializer is being used for).
To handle this correctly the attached patch introduces
a new function, type_initializer_zero_p, that takes in addition
to an initializer also the type it is being used to initialize.
The function then traverses both arguments and returns true only
if each string is being used to initialize an array and false if
any of them is being used to initialize a pointer.
Since the function is generic the patch adds it to tree.c rather
than somewhere in the C++ front-end.
Tested on x86_64-linux.
Martin
PR c++/90947 - Simple lookup table of array of strings is miscompiled
gcc/cp/ChangeLog:
PR c++/90947
* decl.c (reshape_init_array_1): Avoid truncating initializer
lists containing string literals.
gcc/testsuite/ChangeLog:
PR c++/90947
* c-c++-common/array-1.c: New test.
* g++.dg/abi/mangle73.C: New test.
* g++.dg/cpp2a/nontype-class18.C: New test.
gcc/ChangeLog:
PR c++/90947
* tree.c (type_initializer_zero_p): Define.
* tree.h (type_initializer_zero_p): New function.
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 98b54d542a0..95893631992 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -5863,8 +5863,9 @@ reshape_init_array_1 (tree elt_type, tree max_index, reshape_iter *d,
/* Pointers initialized to strings must be treated as non-zero
even if the string is empty. */
tree init_type = TREE_TYPE (elt_init);
- if ((POINTER_TYPE_P (elt_type) != POINTER_TYPE_P (init_type))
- || !initializer_zerop (elt_init))
+ if ((POINTER_TYPE_P (elt_type) != POINTER_TYPE_P (init_type)))
+ last_nonzero = index;
+ else if (!type_initializer_zero_p (elt_type, elt_init))
last_nonzero = index;
/* This can happen with an invalid initializer (c++/54501). */
diff --git a/gcc/testsuite/c-c++-common/array-1.c b/gcc/testsuite/c-c++-common/array-1.c
new file mode 100644
index 000..5de9ade4d43
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/array-1.c
@@ -0,0 +1,247 @@
+// PR c++/90947 - Simple lookup table of array of strings is miscompiled
+// { dg-do compile }
+// { dg-options "-O1 -fdump-tree-optimized" }
+
+#define assert(expr) ((expr) ? (void)0 : __builtin_abort ())
+
+void pr90947 (void)
+{
+ int vecsize = 4;
+ int index = 0;
+ static const char *a[4][4] =
+{
+ { ".x", ".y", ".z", ".w" },
+ { ".xy", ".yz", ".zw", 0 },
+ { ".xyz", ".yzw", 0, 0 },
+ { "", 0, 0, 0 },
+};
+
+ assert (vecsize >= 1 && vecsize <= 4);
+ assert (index >= 0 && index < 4);
+ assert (a[vecsize - 1][index]);
+}
+
+void f_a1_1 (void)
+{
+ {
+const char* a[1][1] = { { 0 } };
+assert (0 == a[0][0]);
+ }
+ {
+const char* a[1][1] = { { "" } };
+assert ('\0' == *a[0][0]);
+ }
+}
+
+void f_a2_1 (void)
+{
+ {
+const char* a[2][1] = { { "" }, { "" } };
+assert ('\0' == *a[0][0] && '\0' == *a[1][0]);
+ }
+ {
+const char* a[2][1] = { { 0 }, { "" } };
+assert (0 == a[0][0] && '\0' == *a[1][0]);
+ }
+ {
+const char* a[2][1] = { { }, { "" } };
+assert (0 == a[0][0] && '\0' == *a[1][0]);
+ }
+}
+
+void f_a2_2 (void)
+{
+ {
+const char* a[2][2] = { { "", "" }, { "", "" } };
+assert ('\0' == *a[0][0] && '\0' == *a[0][1]);
+assert ('\0' == *a[1][0] && '\0' == *a[1][1]);
+ }
+ {
+const char* a[2][2] = { { "", "" }, { "", 0 } };
+assert ('\0' == *a[0][0] && '\0' == *a[0][1]);
+assert ('\0' == *a[1][0] && 0 == a[1][1]);
+ }
+ {
+const char* a[2][2] = { { "", "" }, { "" } };
+assert ('\0' == *a[0][0] && '\0' == *a[0][1]);
+assert ('\0' == *a[1][0] && 0 == a[1][1]);
+ }
+ {
+const char* a[2][2] = { { "", "" }, { 0, "" } };
+assert ('\0' == *a[0][0] && '\0' == *a[0][1]);
+assert (0 == a[1][0] && '\0' == *a[1][1]);
+ }
+ {
+const char* a[2][2] = { { "", 0 }, { 0, "" } };
+assert ('\0' == *a[0][0] && 0 == a[0][1]);
+assert (0 == a[1][0] && '\0' == *a[1][1]);
+ }
+ {
+const char* a[2][2] = { { 0, 0 }, { 0, "" } };
+assert (0 == a[0][0] && 0 == a[0][1]);
+assert (0 == a[1][0] && '\0' == *a[1][1]);
+ }
+ {
+const char* a[2][2] = { { 0 }, { 0, "" } };
+assert (0 == a[0][0] && 0 == a[0][1]);
+assert (0 == a[1][0] && '\0' == *a[1][1]);
+ }
+ {
+const char* a[2][2] = { { }, { 0, "" } };
+assert (0 == a[0][0] && 0 == a[0][1]);
+assert (0 ==
