* [Bug c/97860] [11 Regression] ICE in handle_argspec_attribute, at c-family/c-attribs.c:3244 since r11-3303-g6450f07388f9fe57
2020-11-16 19:00 [Bug c/97860] New: [11 Regression] ICE in handle_argspec_attribute, at c-family/c-attribs.c:3244 gscfq@t-online.de
@ 2020-11-16 19:41 ` marxin at gcc dot gnu.org
2020-11-17 7:15 ` rguenth at gcc dot gnu.org
` (8 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: marxin at gcc dot gnu.org @ 2020-11-16 19:41 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97860
Martin Liška <marxin at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Known to work| |10.2.0
Target Milestone|--- |11.0
CC| |marxin at gcc dot gnu.org,
| |msebor at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Known to fail| |11.0
Summary|[11 Regression] ICE in |[11 Regression] ICE in
|handle_argspec_attribute, |handle_argspec_attribute,
|at |at
|c-family/c-attribs.c:3244 |c-family/c-attribs.c:3244
| |since
| |r11-3303-g6450f07388f9fe57
Last reconfirmed| |2020-11-16
Ever confirmed|0 |1
--- Comment #1 from Martin Liška <marxin at gcc dot gnu.org> ---
Thank you for the report.
Started with r11-3303-g6450f07388f9fe57.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug c/97860] [11 Regression] ICE in handle_argspec_attribute, at c-family/c-attribs.c:3244 since r11-3303-g6450f07388f9fe57
2020-11-16 19:00 [Bug c/97860] New: [11 Regression] ICE in handle_argspec_attribute, at c-family/c-attribs.c:3244 gscfq@t-online.de
2020-11-16 19:41 ` [Bug c/97860] [11 Regression] ICE in handle_argspec_attribute, at c-family/c-attribs.c:3244 since r11-3303-g6450f07388f9fe57 marxin at gcc dot gnu.org
@ 2020-11-17 7:15 ` rguenth at gcc dot gnu.org
2020-11-18 14:19 ` jakub at gcc dot gnu.org
` (7 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: rguenth at gcc dot gnu.org @ 2020-11-17 7:15 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97860
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P3 |P1
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug c/97860] [11 Regression] ICE in handle_argspec_attribute, at c-family/c-attribs.c:3244 since r11-3303-g6450f07388f9fe57
2020-11-16 19:00 [Bug c/97860] New: [11 Regression] ICE in handle_argspec_attribute, at c-family/c-attribs.c:3244 gscfq@t-online.de
2020-11-16 19:41 ` [Bug c/97860] [11 Regression] ICE in handle_argspec_attribute, at c-family/c-attribs.c:3244 since r11-3303-g6450f07388f9fe57 marxin at gcc dot gnu.org
2020-11-17 7:15 ` rguenth at gcc dot gnu.org
@ 2020-11-18 14:19 ` jakub at gcc dot gnu.org
2020-11-18 15:40 ` msebor at gcc dot gnu.org
` (6 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-11-18 14:19 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97860
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The problem is that in the C FE TYPE_MAX_VALUE (TYPE_DOMAIN (type)) isn't set
for the [0] types (yet they are complete), while the middle-end expects for
them to have TYPE_MAX_VALUE of -1 or so, so array_type_nelts returns
error_mark_node.
We could do:
/* array_type_nelts assumes the middle-end TYPE_DOMAINs, while
GNU [0] array in the FE don't have TYPE_MAX_VALUE of the
domain set, yet they are complete types with no elements. */
if (nelts == error_mark_node
&& TYPE_DOMAIN (type)
&& !TYPE_MAX_VALUE (TYPE_DOMAIN (type))
&& COMPLETE_P (type)
&& integer_zerop (TYPE_SIZE (type)))
continue;
but then it doesn't make sense to queue up error_mark_nodes in the attributes
when we ICE on them later, so perhaps better:
2020-11-18 Jakub Jelinek <jakub@redhat.com>
PR c/97860
* c-decl.c (get_parm_array_spec): Don't chain error_mark_node as
VLA bounds.
* gcc.dg/pr97860.c: New test.
--- gcc/c/c-decl.c.jj 2020-11-11 01:46:03.245697697 +0100
+++ gcc/c/c-decl.c 2020-11-18 15:11:14.613565216 +0100
@@ -5775,7 +5775,7 @@ get_parm_array_spec (const struct c_parm
type = TREE_TYPE (type))
{
tree nelts = array_type_nelts (type);
- if (TREE_CODE (nelts) != INTEGER_CST)
+ if (TREE_CODE (nelts) != INTEGER_CST && nelts != error_mark_node)
{
/* Each variable VLA bound is represented by the dollar
sign. */
--- gcc/testsuite/gcc.dg/pr97860.c.jj 2020-11-18 15:15:08.858931877 +0100
+++ gcc/testsuite/gcc.dg/pr97860.c 2020-11-18 15:14:50.751135430 +0100
@@ -0,0 +1,11 @@
+/* PR c/97860 */
+/* { dg-do compile } */
+/* { dg-options "" } */
+
+void
+foo (int n)
+{
+ typedef int T[0];
+ typedef T V[n];
+ void bar (V);
+}
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug c/97860] [11 Regression] ICE in handle_argspec_attribute, at c-family/c-attribs.c:3244 since r11-3303-g6450f07388f9fe57
2020-11-16 19:00 [Bug c/97860] New: [11 Regression] ICE in handle_argspec_attribute, at c-family/c-attribs.c:3244 gscfq@t-online.de
` (2 preceding siblings ...)
2020-11-18 14:19 ` jakub at gcc dot gnu.org
@ 2020-11-18 15:40 ` msebor at gcc dot gnu.org
2020-11-18 15:42 ` jakub at gcc dot gnu.org
` (5 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: msebor at gcc dot gnu.org @ 2020-11-18 15:40 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97860
--- Comment #3 from Martin Sebor <msebor at gcc dot gnu.org> ---
I was going to commit the following but I'll leave it to you.
diff --git a/gcc/c/c-decl.c b/gcc/c/c-decl.c
index d348e39c27a..95cf9e4cb00 100644
--- a/gcc/c/c-decl.c
+++ b/gcc/c/c-decl.c
@@ -5775,6 +5775,10 @@ get_parm_array_spec (const struct c_parm *parm, tree
attrs)
type = TREE_TYPE (type))
{
tree nelts = array_type_nelts (type);
+ if (error_operand_p (nelts))
+ /* Avoid erroneous expressions. */
+ return attrs;
+
if (TREE_CODE (nelts) != INTEGER_CST)
{
/* Each variable VLA bound is represented by the dollar
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug c/97860] [11 Regression] ICE in handle_argspec_attribute, at c-family/c-attribs.c:3244 since r11-3303-g6450f07388f9fe57
2020-11-16 19:00 [Bug c/97860] New: [11 Regression] ICE in handle_argspec_attribute, at c-family/c-attribs.c:3244 gscfq@t-online.de
` (3 preceding siblings ...)
2020-11-18 15:40 ` msebor at gcc dot gnu.org
@ 2020-11-18 15:42 ` jakub at gcc dot gnu.org
2020-11-18 16:37 ` msebor at gcc dot gnu.org
` (4 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-11-18 15:42 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97860
--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Martin Sebor from comment #3)
> I was going to commit the following but I'll leave it to you.
>
> diff --git a/gcc/c/c-decl.c b/gcc/c/c-decl.c
> index d348e39c27a..95cf9e4cb00 100644
> --- a/gcc/c/c-decl.c
> +++ b/gcc/c/c-decl.c
> @@ -5775,6 +5775,10 @@ get_parm_array_spec (const struct c_parm *parm, tree
> attrs)
> type = TREE_TYPE (type))
> {
> tree nelts = array_type_nelts (type);
> + if (error_operand_p (nelts))
> + /* Avoid erroneous expressions. */
> + return attrs;
> +
> if (TREE_CODE (nelts) != INTEGER_CST)
> {
> /* Each variable VLA bound is represented by the dollar
For errors why not, but typedef int T[0]; really is not an error actually.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug c/97860] [11 Regression] ICE in handle_argspec_attribute, at c-family/c-attribs.c:3244 since r11-3303-g6450f07388f9fe57
2020-11-16 19:00 [Bug c/97860] New: [11 Regression] ICE in handle_argspec_attribute, at c-family/c-attribs.c:3244 gscfq@t-online.de
` (4 preceding siblings ...)
2020-11-18 15:42 ` jakub at gcc dot gnu.org
@ 2020-11-18 16:37 ` msebor at gcc dot gnu.org
2020-11-18 16:43 ` jakub at gcc dot gnu.org
` (3 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: msebor at gcc dot gnu.org @ 2020-11-18 16:37 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97860
--- Comment #5 from Martin Sebor <msebor at gcc dot gnu.org> ---
Actually, I missed that your patch just skips over the error node. That will
leave the attribute spec out of sync with the argument (it contains a '$' for
each VLA bound). Rather than continuing to the next bound I think we should
bail. The alternative is to change the rest of the code (the attribute handler
and the whole attribute access machinery) to skip these erroneous bounds.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug c/97860] [11 Regression] ICE in handle_argspec_attribute, at c-family/c-attribs.c:3244 since r11-3303-g6450f07388f9fe57
2020-11-16 19:00 [Bug c/97860] New: [11 Regression] ICE in handle_argspec_attribute, at c-family/c-attribs.c:3244 gscfq@t-online.de
` (5 preceding siblings ...)
2020-11-18 16:37 ` msebor at gcc dot gnu.org
@ 2020-11-18 16:43 ` jakub at gcc dot gnu.org
2020-11-18 17:13 ` msebor at gcc dot gnu.org
` (2 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-11-18 16:43 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97860
--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
As I said, [0] is not a VLA bound.
And we don't record anything for constant bounds (even if they are in the
middle).
So perhaps:
/* array_type_nelts assumes the middle-end TYPE_DOMAINs, while
GNU [0] array in the FE don't have TYPE_MAX_VALUE of the
domain set, yet they are complete types with no elements. */
if (nelts == error_mark_node
&& TYPE_DOMAIN (type)
&& !TYPE_MAX_VALUE (TYPE_DOMAIN (type))
&& COMPLETE_P (type)
&& integer_zerop (TYPE_SIZE (type)))
continue;
if (error_mark_operand (nelts))
return attrs;
which would bail for errors, but would handle [0] complete arrays as
non-errors.
After all, even for those it might be meaningful to complain about out of
bounds accesses.
Sure, for [0] arrays all dereferences are invalid, but taking address of
element [0] is ok.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug c/97860] [11 Regression] ICE in handle_argspec_attribute, at c-family/c-attribs.c:3244 since r11-3303-g6450f07388f9fe57
2020-11-16 19:00 [Bug c/97860] New: [11 Regression] ICE in handle_argspec_attribute, at c-family/c-attribs.c:3244 gscfq@t-online.de
` (6 preceding siblings ...)
2020-11-18 16:43 ` jakub at gcc dot gnu.org
@ 2020-11-18 17:13 ` msebor at gcc dot gnu.org
2020-11-19 19:10 ` cvs-commit at gcc dot gnu.org
2020-11-19 20:53 ` jakub at gcc dot gnu.org
9 siblings, 0 replies; 11+ messages in thread
From: msebor at gcc dot gnu.org @ 2020-11-18 17:13 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97860
--- Comment #7 from Martin Sebor <msebor at gcc dot gnu.org> ---
What I mean is that unless error_mark_node necessarily implies (and guarantees)
the bound is a constant zero (as opposed to a similarly "broken" VLA bound),
simply bailing is safer than skipping it. I have no idea if the front end
guarantees it but I don't see it mentioned in array_type_nelts(). If it is
guaranteed then continuing is fine but it should also be documented in the
comment above array_type_nelts(), and I would suggest to also mention it in the
change to get_parm_array_spec.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug c/97860] [11 Regression] ICE in handle_argspec_attribute, at c-family/c-attribs.c:3244 since r11-3303-g6450f07388f9fe57
2020-11-16 19:00 [Bug c/97860] New: [11 Regression] ICE in handle_argspec_attribute, at c-family/c-attribs.c:3244 gscfq@t-online.de
` (7 preceding siblings ...)
2020-11-18 17:13 ` msebor at gcc dot gnu.org
@ 2020-11-19 19:10 ` cvs-commit at gcc dot gnu.org
2020-11-19 20:53 ` jakub at gcc dot gnu.org
9 siblings, 0 replies; 11+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2020-11-19 19:10 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97860
--- Comment #8 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:8156cfaa4c45f1249bbdda29d04b4fef84b7eafe
commit r11-5180-g8156cfaa4c45f1249bbdda29d04b4fef84b7eafe
Author: Jakub Jelinek <jakub@redhat.com>
Date: Thu Nov 19 20:02:41 2020 +0100
c, tree: Fix ICE from get_parm_array_spec [PR97860]
The C and C++ FEs handle zero sized arrays differently, C uses
NULL TYPE_MAX_VALUE on non-NULL TYPE_DOMAIN on complete ARRAY_TYPEs
with bitsize_zero_node TYPE_SIZE, while C++ FE likes to set
TYPE_MAX_VALUE to the largest value (and min to the lowest).
Martin has used array_type_nelts in get_parm_array_spec where the
function on the C form of [0] arrays returns error_mark_node and the code
crashes soon afterwards. The following patch teaches array_type_nelts
about
this (e.g. dwarf2out already handles that as [0]). While it will change
what is_empty_type returns for certain types (e.g. struct S { int a[0];
};),
as those types occupy zero bits in C, it should make an ABI difference.
So, the tree.c change makes the c-decl.c code handle the [0] arrays
like any other constant extents, and the c-decl.c change just makes sure
that if we'd run into error_mark_node e.g. from the VLA expressions, we
don't crash on those.
2020-11-19 Jakub Jelinek <jakub@redhat.com>
PR c/97860
* tree.c (array_type_nelts): For complete arrays with zero min
and NULL max and zero size return -1.
* c-decl.c (get_parm_array_spec): Bail out of nelts is
error_operand_p.
* gcc.dg/pr97860.c: New test.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug c/97860] [11 Regression] ICE in handle_argspec_attribute, at c-family/c-attribs.c:3244 since r11-3303-g6450f07388f9fe57
2020-11-16 19:00 [Bug c/97860] New: [11 Regression] ICE in handle_argspec_attribute, at c-family/c-attribs.c:3244 gscfq@t-online.de
` (8 preceding siblings ...)
2020-11-19 19:10 ` cvs-commit at gcc dot gnu.org
@ 2020-11-19 20:53 ` jakub at gcc dot gnu.org
9 siblings, 0 replies; 11+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-11-19 20:53 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97860
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed.
^ permalink raw reply [flat|nested] 11+ messages in thread