Re: [PATCH v3] Fix ICE when mixing VLAs and statement expressions [PR91038]
On 10/2/21 15:06, Uecker, Martin wrote:
Am Donnerstag, den 23.09.2021, 17:37 -0400 schrieb Jason Merrill:
On 9/23/21 15:49, Uecker, Martin wrote:
Am Mittwoch, den 22.09.2021, 17:18 -0400 schrieb Jason Merrill:
On 9/5/21 15:14, Uecker, Martin wrote:
Here is the third version of the patch. This also
fixes the index zero case. Thus, this should be
a complete fix for 91038 and should fix all cases
also supported by clang. Still not working is
returning a struct of variable size from a
statement expression (29970) when the size depends
on computations inside the statement expression.
Bootstrapped and regression tested
on x86-64 for all languages.
Martin
Fix ICE when mixing VLAs and statement expressions [PR91038]
When returning VM-types from statement expressions, this can
lead to an ICE when declarations from the statement expression
are referred to later. Most of these issues can be addressed by
gimplifying the base expression earlier in gimplify_compound_lval.
Another issue is fixed by not reording some size-related expressions
during folding. This fixes PR91038 and some of the test cases
from PR29970 (structs with VLA members need further work).
2021-08-01 Martin Uecker
gcc/
PR c/91038
PR c/29970
* gimplify.c (gimplify_var_or_parm_decl): Update comment.
(gimplify_compound_lval): Gimplify base expression first.
(gimplify_target_expr): Do not gimplify size expression.
* fold-const.c (fold_binary_loc): Do not reorder SAVE_EXPR
in pointer arithmetic for variably modified types.
gcc/testsuite/
PR c/91038
PR c/29970
* gcc.dg/vla-stexp-3.c: New test.
* gcc.dg/vla-stexp-4.c: New test.
* gcc.dg/vla-stexp-5.c: New test.
* gcc.dg/vla-stexp-6.c: New test.
* gcc.dg/vla-stexp-7.c: New test.
* gcc.dg/vla-stexp-8.c: New test.
* gcc.dg/vla-stexp-9.c: New test.
diff --git a/gcc/fold-const.c b/gcc/fold-const.c
index ff23f12f33c..1e6f50692b5 100644
--- a/gcc/fold-const.c
+++ b/gcc/fold-const.c
@@ -10854,7 +10854,15 @@ fold_binary_loc (location_t loc, enum tree_code code,
tree type,
return build2_loc (loc, COMPOUND_EXPR, type, TREE_OPERAND (arg0, 0),
tem);
}
- if (TREE_CODE (arg1) == COMPOUND_EXPR)
+ /* This interleaves execution of the two sub-expressions
+which is allowed in C. For pointer arithmetic when the
+the pointer has a variably modified type, the right expression
+might have a SAVE_EXPR which depends on the left expr, so
+do not fold in this case. */
+ if (TREE_CODE (arg1) == COMPOUND_EXPR
+ && !(code == POINTER_PLUS_EXPR
+ && TREE_CODE (TREE_OPERAND (arg1, 0)) == SAVE_EXPR)
+ && variably_modified_type_p (type, NULL_TREE))
This seems pretty fragile. If the problem is that the SAVE_EXPR depends
on a statement-expr on the LHS, can't that happen with expressions other
than POINTER_PLUS_EXPR?
I intentionally limited the change to this specific
case to avoid accidentally breaking or pessimizing
anything else. I did not notice any other cases that
need fixing. It is of course possible that
I have missed some...
Maybe we should include the statement-expr in the SAVE_EXPR?
I am not really sure how to implement this.
Nor am I, I'm not at all familiar with the VLA handling code. But if
the generated trees rely on evaluation happening with a stricter order
than is actually guaranteed, that seems like a bug in the generation of
the expression trees, not the folding code.
Is there a definition about what is guaranteed?
It seems to be based on the somewhat scary
C semantics where in
(a, b) op (c, d)
evaluation order could be
a, c, b, d.
Exactly. Or c, d, a, b, for that matter.
If I remember correctly
({ int N; int x[N]; })[0]
becomes
TARGET_EXPR + (SAVE_EXPR * 0)
which (somehow involving the rule above) becomes
SAVE_EXPR ; TARGET_EXPR
It looks like the problem comes when pointer_int_sum multiplies size_exp
by constant 0, which gets folded into a COMPOUND_EXPR, which is
problematic here.
The simplest fix is probably for pointer_int_sum to avoid doing the
multiplication with a 0 index.
More generally, the problem is that pointer_int_sum assumes that the
element size can be evaluated without previously evaluating the pointer
operand. Given
p + sizeof(*p)*off
we could turn that into
SAVE_EXPR + (SAVE_EXPR, sizeof(*p)*off)
so that p is evaluated before sizeof(*p) regardless of transformations.
It probably makes sense to condition that on if sizeof(*p) is
TREE_SIDE_EFFECTS.
Could someone that knows more about VLA weigh in?
Maybe we could apply this patch first (because
I have to work around this bug in a couple of
projects which is a bit annoying)? I am happy
to implement an alternative later if there is
a better way (which I can understand).
The
Re: [PATCH v3] Fix ICE when mixing VLAs and statement expressions [PR91038]
Am Donnerstag, den 23.09.2021, 17:37 -0400 schrieb Jason Merrill:
> On 9/23/21 15:49, Uecker, Martin wrote:
> > Am Mittwoch, den 22.09.2021, 17:18 -0400 schrieb Jason Merrill:
> > > On 9/5/21 15:14, Uecker, Martin wrote:
> > > > Here is the third version of the patch. This also
> > > > fixes the index zero case. Thus, this should be
> > > > a complete fix for 91038 and should fix all cases
> > > > also supported by clang. Still not working is
> > > > returning a struct of variable size from a
> > > > statement expression (29970) when the size depends
> > > > on computations inside the statement expression.
> > > >
> > > > Bootstrapped and regression tested
> > > > on x86-64 for all languages.
> > > >
> > > > Martin
> > > >
> > > >
> > > >
> > > >
> > > > Fix ICE when mixing VLAs and statement expressions [PR91038]
> > > >
> > > > When returning VM-types from statement expressions, this can
> > > > lead to an ICE when declarations from the statement expression
> > > > are referred to later. Most of these issues can be addressed by
> > > > gimplifying the base expression earlier in gimplify_compound_lval.
> > > > Another issue is fixed by not reording some size-related expressions
> > > > during folding. This fixes PR91038 and some of the test cases
> > > > from PR29970 (structs with VLA members need further work).
> > > >
> > > >
> > > > 2021-08-01 Martin Uecker
> > > >
> > > > gcc/
> > > > PR c/91038
> > > > PR c/29970
> > > > * gimplify.c (gimplify_var_or_parm_decl): Update comment.
> > > > (gimplify_compound_lval): Gimplify base expression first.
> > > > (gimplify_target_expr): Do not gimplify size expression.
> > > > * fold-const.c (fold_binary_loc): Do not reorder SAVE_EXPR
> > > > in pointer arithmetic for variably modified types.
> > > >
> > > > gcc/testsuite/
> > > > PR c/91038
> > > > PR c/29970
> > > > * gcc.dg/vla-stexp-3.c: New test.
> > > > * gcc.dg/vla-stexp-4.c: New test.
> > > > * gcc.dg/vla-stexp-5.c: New test.
> > > > * gcc.dg/vla-stexp-6.c: New test.
> > > > * gcc.dg/vla-stexp-7.c: New test.
> > > > * gcc.dg/vla-stexp-8.c: New test.
> > > > * gcc.dg/vla-stexp-9.c: New test.
> > > >
> > > >
> > > > diff --git a/gcc/fold-const.c b/gcc/fold-const.c
> > > > index ff23f12f33c..1e6f50692b5 100644
> > > > --- a/gcc/fold-const.c
> > > > +++ b/gcc/fold-const.c
> > > > @@ -10854,7 +10854,15 @@ fold_binary_loc (location_t loc, enum
> > > > tree_code code, tree type,
> > > > return build2_loc (loc, COMPOUND_EXPR, type, TREE_OPERAND
> > > > (arg0, 0),
> > > > tem);
> > > > }
> > > > - if (TREE_CODE (arg1) == COMPOUND_EXPR)
> > > > + /* This interleaves execution of the two sub-expressions
> > > > +which is allowed in C. For pointer arithmetic when the
> > > > +the pointer has a variably modified type, the right expression
> > > > +might have a SAVE_EXPR which depends on the left expr, so
> > > > +do not fold in this case. */
> > > > + if (TREE_CODE (arg1) == COMPOUND_EXPR
> > > > + && !(code == POINTER_PLUS_EXPR
> > > > + && TREE_CODE (TREE_OPERAND (arg1, 0)) == SAVE_EXPR)
> > > > + && variably_modified_type_p (type, NULL_TREE))
> > >
> > > This seems pretty fragile. If the problem is that the SAVE_EXPR depends
> > > on a statement-expr on the LHS, can't that happen with expressions other
> > > than POINTER_PLUS_EXPR?
> >
> > I intentionally limited the change to this specific
> > case to avoid accidentally breaking or pessimizing
> > anything else. I did not notice any other cases that
> > need fixing. It is of course possible that
> > I have missed some...
> >
> > > Maybe we should include the statement-expr in the SAVE_EXPR?
> >
> > I am not really sure how to implement this.
>
> Nor am I, I'm not at all familiar with the VLA handling code. But if
> the generated trees rely on evaluation happening with a stricter order
> than is actually guaranteed, that seems like a bug in the generation of
> the expression trees, not the folding code.
Is there a definition about what is guaranteed?
It seems to be based on the somewhat scary
C semantics where in
(a, b) op (c, d)
evaluation order could be
a, c, b, d.
If I remember correctly
({ int N; int x[N]; })[0]
becomes
TARGET_EXPR + (SAVE_EXPR * 0)
which (somehow involving the rule above) becomes
SAVE_EXPR ; TARGET_EXPR Could someone that knows more about VLA weigh in?
> > Maybe we could apply this patch first (because
> > I have to work around this bug in a couple of
> > projects which is a bit annoying)? I am happy
> > to implement an alternative later if there is
> > a better way (which I can understand).
>
> The gimplify_compound_lval change is OK now.
>
> What's the rationale for the gimplify_target_expr change?
It
Re: [PATCH v3] Fix ICE when mixing VLAs and statement expressions [PR91038]
On 9/23/21 15:49, Uecker, Martin wrote:
Am Mittwoch, den 22.09.2021, 17:18 -0400 schrieb Jason Merrill:
On 9/5/21 15:14, Uecker, Martin wrote:
Here is the third version of the patch. This also
fixes the index zero case. Thus, this should be
a complete fix for 91038 and should fix all cases
also supported by clang. Still not working is
returning a struct of variable size from a
statement expression (29970) when the size depends
on computations inside the statement expression.
Bootstrapped and regression tested
on x86-64 for all languages.
Martin
Fix ICE when mixing VLAs and statement expressions [PR91038]
When returning VM-types from statement expressions, this can
lead to an ICE when declarations from the statement expression
are referred to later. Most of these issues can be addressed by
gimplifying the base expression earlier in gimplify_compound_lval.
Another issue is fixed by not reording some size-related expressions
during folding. This fixes PR91038 and some of the test cases
from PR29970 (structs with VLA members need further work).
2021-08-01 Martin Uecker
gcc/
PR c/91038
PR c/29970
* gimplify.c (gimplify_var_or_parm_decl): Update comment.
(gimplify_compound_lval): Gimplify base expression first.
(gimplify_target_expr): Do not gimplify size expression.
* fold-const.c (fold_binary_loc): Do not reorder SAVE_EXPR
in pointer arithmetic for variably modified types.
gcc/testsuite/
PR c/91038
PR c/29970
* gcc.dg/vla-stexp-3.c: New test.
* gcc.dg/vla-stexp-4.c: New test.
* gcc.dg/vla-stexp-5.c: New test.
* gcc.dg/vla-stexp-6.c: New test.
* gcc.dg/vla-stexp-7.c: New test.
* gcc.dg/vla-stexp-8.c: New test.
* gcc.dg/vla-stexp-9.c: New test.
diff --git a/gcc/fold-const.c b/gcc/fold-const.c
index ff23f12f33c..1e6f50692b5 100644
--- a/gcc/fold-const.c
+++ b/gcc/fold-const.c
@@ -10854,7 +10854,15 @@ fold_binary_loc (location_t loc, enum tree_code code,
tree type,
return build2_loc (loc, COMPOUND_EXPR, type, TREE_OPERAND (arg0, 0),
tem);
}
- if (TREE_CODE (arg1) == COMPOUND_EXPR)
+ /* This interleaves execution of the two sub-expressions
+which is allowed in C. For pointer arithmetic when the
+the pointer has a variably modified type, the right expression
+might have a SAVE_EXPR which depends on the left expr, so
+do not fold in this case. */
+ if (TREE_CODE (arg1) == COMPOUND_EXPR
+ && !(code == POINTER_PLUS_EXPR
+ && TREE_CODE (TREE_OPERAND (arg1, 0)) == SAVE_EXPR)
+ && variably_modified_type_p (type, NULL_TREE))
This seems pretty fragile. If the problem is that the SAVE_EXPR depends
on a statement-expr on the LHS, can't that happen with expressions other
than POINTER_PLUS_EXPR?
I intentionally limited the change to this specific
case to avoid accidentally breaking or pessimizing
anything else. I did not notice any other cases that
need fixing. It is of course possible that
I have missed some...
Maybe we should include the statement-expr in the SAVE_EXPR?
I am not really sure how to implement this.
Nor am I, I'm not at all familiar with the VLA handling code. But if
the generated trees rely on evaluation happening with a stricter order
than is actually guaranteed, that seems like a bug in the generation of
the expression trees, not the folding code.
Could someone that knows more about VLA weigh in?
Maybe we could apply this patch first (because
I have to work around this bug in a couple of
projects which is a bit annoying)? I am happy
to implement an alternative later if there is
a better way (which I can understand).
The gimplify_compound_lval change is OK now.
What's the rationale for the gimplify_target_expr change?
{
tem = fold_build2_loc (loc, code, type, op0,
fold_convert_loc (loc, TREE_TYPE (op1),
diff --git a/gcc/gimplify.c b/gcc/gimplify.c
index 99d1c7fcce4..8ee205f593c 100644
--- a/gcc/gimplify.c
+++ b/gcc/gimplify.c
@@ -2840,7 +2840,10 @@ gimplify_var_or_parm_decl (tree *expr_p)
declaration, for which we've already issued an error. It would
be really nice if the front end wouldn't leak these at all.
Currently the only known culprit is C++ destructors, as seen
- in g++.old-deja/g++.jason/binding.C. */
+ in g++.old-deja/g++.jason/binding.C.
+ Another possible culpit are size expressions for variably modified
+ types which are lost in the FE or not gimplified correctly.
+ */
if (VAR_P (decl)
&& !DECL_SEEN_IN_BIND_EXPR_P (decl)
&& !TREE_STATIC (decl) && !DECL_EXTERNAL (decl)
@@ -2985,16 +2988,22 @@ gimplify_compound_lval (tree *expr_p, gimple_seq
*pre_p, gimple_seq
*post_p,
expression until we deal with any variable bounds, sizes, or
Re: [PATCH v3] Fix ICE when mixing VLAs and statement expressions [PR91038]
Am Mittwoch, den 22.09.2021, 17:18 -0400 schrieb Jason Merrill:
> On 9/5/21 15:14, Uecker, Martin wrote:
> > Here is the third version of the patch. This also
> > fixes the index zero case. Thus, this should be
> > a complete fix for 91038 and should fix all cases
> > also supported by clang. Still not working is
> > returning a struct of variable size from a
> > statement expression (29970) when the size depends
> > on computations inside the statement expression.
> >
> > Bootstrapped and regression tested
> > on x86-64 for all languages.
> >
> > Martin
> >
> >
> >
> >
> > Fix ICE when mixing VLAs and statement expressions [PR91038]
> >
> > When returning VM-types from statement expressions, this can
> > lead to an ICE when declarations from the statement expression
> > are referred to later. Most of these issues can be addressed by
> > gimplifying the base expression earlier in gimplify_compound_lval.
> > Another issue is fixed by not reording some size-related expressions
> > during folding. This fixes PR91038 and some of the test cases
> > from PR29970 (structs with VLA members need further work).
> >
> >
> > 2021-08-01 Martin Uecker
> >
> > gcc/
> > PR c/91038
> > PR c/29970
> > * gimplify.c (gimplify_var_or_parm_decl): Update comment.
> > (gimplify_compound_lval): Gimplify base expression first.
> > (gimplify_target_expr): Do not gimplify size expression.
> > * fold-const.c (fold_binary_loc): Do not reorder SAVE_EXPR
> > in pointer arithmetic for variably modified types.
> >
> > gcc/testsuite/
> > PR c/91038
> > PR c/29970
> > * gcc.dg/vla-stexp-3.c: New test.
> > * gcc.dg/vla-stexp-4.c: New test.
> > * gcc.dg/vla-stexp-5.c: New test.
> > * gcc.dg/vla-stexp-6.c: New test.
> > * gcc.dg/vla-stexp-7.c: New test.
> > * gcc.dg/vla-stexp-8.c: New test.
> > * gcc.dg/vla-stexp-9.c: New test.
> >
> >
> > diff --git a/gcc/fold-const.c b/gcc/fold-const.c
> > index ff23f12f33c..1e6f50692b5 100644
> > --- a/gcc/fold-const.c
> > +++ b/gcc/fold-const.c
> > @@ -10854,7 +10854,15 @@ fold_binary_loc (location_t loc, enum tree_code
> > code, tree type,
> > return build2_loc (loc, COMPOUND_EXPR, type, TREE_OPERAND (arg0, 0),
> > tem);
> > }
> > - if (TREE_CODE (arg1) == COMPOUND_EXPR)
> > + /* This interleaves execution of the two sub-expressions
> > +which is allowed in C. For pointer arithmetic when the
> > +the pointer has a variably modified type, the right expression
> > +might have a SAVE_EXPR which depends on the left expr, so
> > +do not fold in this case. */
> > + if (TREE_CODE (arg1) == COMPOUND_EXPR
> > + && !(code == POINTER_PLUS_EXPR
> > + && TREE_CODE (TREE_OPERAND (arg1, 0)) == SAVE_EXPR)
> > + && variably_modified_type_p (type, NULL_TREE))
>
> This seems pretty fragile. If the problem is that the SAVE_EXPR depends
> on a statement-expr on the LHS, can't that happen with expressions other
> than POINTER_PLUS_EXPR?
I intentionally limited the change to this specific
case to avoid accidentally breaking or pessimizing
anything else. I did not notice any other cases that
need fixing. It is of course possible that
I have missed some...
>
> Maybe we should include the statement-expr in the SAVE_EXPR?
I am not really sure how to implement this.
Maybe we could apply this patch first (because
I have to work around this bug in a couple of
projects which is a bit annoying)? I am happy
to implement an alternative later if there is
a better way (which I can understand).
Martin
> > {
> > tem = fold_build2_loc (loc, code, type, op0,
> > fold_convert_loc (loc, TREE_TYPE (op1),
> > diff --git a/gcc/gimplify.c b/gcc/gimplify.c
> > index 99d1c7fcce4..8ee205f593c 100644
> > --- a/gcc/gimplify.c
> > +++ b/gcc/gimplify.c
> > @@ -2840,7 +2840,10 @@ gimplify_var_or_parm_decl (tree *expr_p)
> >declaration, for which we've already issued an error. It would
> >be really nice if the front end wouldn't leak these at all.
> >Currently the only known culprit is C++ destructors, as seen
> > - in g++.old-deja/g++.jason/binding.C. */
> > + in g++.old-deja/g++.jason/binding.C.
> > + Another possible culpit are size expressions for variably modified
> > + types which are lost in the FE or not gimplified correctly.
> > + */
> > if (VAR_P (decl)
> > && !DECL_SEEN_IN_BIND_EXPR_P (decl)
> > && !TREE_STATIC (decl) && !DECL_EXTERNAL (decl)
> > @@ -2985,16 +2988,22 @@ gimplify_compound_lval (tree *expr_p, gimple_seq
> > *pre_p, gimple_seq
> > *post_p,
> >expression until we deal with any variable bounds, sizes, or
> >positions in order to deal with PLACEHOLDER_EXPRs.
> >
> > - So we do this in three steps. First we deal with the annotations
> > - for any variables in the components, then we gimplify the base,
Re: [PATCH v3] Fix ICE when mixing VLAs and statement expressions [PR91038]
On 9/5/21 15:14, Uecker, Martin wrote:
Here is the third version of the patch. This also
fixes the index zero case. Thus, this should be
a complete fix for 91038 and should fix all cases
also supported by clang. Still not working is
returning a struct of variable size from a
statement expression (29970) when the size depends
on computations inside the statement expression.
Bootstrapped and regression tested
on x86-64 for all languages.
Martin
Fix ICE when mixing VLAs and statement expressions [PR91038]
When returning VM-types from statement expressions, this can
lead to an ICE when declarations from the statement expression
are referred to later. Most of these issues can be addressed by
gimplifying the base expression earlier in gimplify_compound_lval.
Another issue is fixed by not reording some size-related expressions
during folding. This fixes PR91038 and some of the test cases
from PR29970 (structs with VLA members need further work).
2021-08-01 Martin Uecker
gcc/
PR c/91038
PR c/29970
* gimplify.c (gimplify_var_or_parm_decl): Update comment.
(gimplify_compound_lval): Gimplify base expression first.
(gimplify_target_expr): Do not gimplify size expression.
* fold-const.c (fold_binary_loc): Do not reorder SAVE_EXPR
in pointer arithmetic for variably modified types.
gcc/testsuite/
PR c/91038
PR c/29970
* gcc.dg/vla-stexp-3.c: New test.
* gcc.dg/vla-stexp-4.c: New test.
* gcc.dg/vla-stexp-5.c: New test.
* gcc.dg/vla-stexp-6.c: New test.
* gcc.dg/vla-stexp-7.c: New test.
* gcc.dg/vla-stexp-8.c: New test.
* gcc.dg/vla-stexp-9.c: New test.
diff --git a/gcc/fold-const.c b/gcc/fold-const.c
index ff23f12f33c..1e6f50692b5 100644
--- a/gcc/fold-const.c
+++ b/gcc/fold-const.c
@@ -10854,7 +10854,15 @@ fold_binary_loc (location_t loc, enum tree_code code,
tree type,
return build2_loc (loc, COMPOUND_EXPR, type, TREE_OPERAND (arg0, 0),
tem);
}
- if (TREE_CODE (arg1) == COMPOUND_EXPR)
+ /* This interleaves execution of the two sub-expressions
+which is allowed in C. For pointer arithmetic when the
+the pointer has a variably modified type, the right expression
+might have a SAVE_EXPR which depends on the left expr, so
+do not fold in this case. */
+ if (TREE_CODE (arg1) == COMPOUND_EXPR
+ && !(code == POINTER_PLUS_EXPR
+ && TREE_CODE (TREE_OPERAND (arg1, 0)) == SAVE_EXPR)
+ && variably_modified_type_p (type, NULL_TREE))
This seems pretty fragile. If the problem is that the SAVE_EXPR depends
on a statement-expr on the LHS, can't that happen with expressions other
than POINTER_PLUS_EXPR?
Maybe we should include the statement-expr in the SAVE_EXPR?
{
tem = fold_build2_loc (loc, code, type, op0,
fold_convert_loc (loc, TREE_TYPE (op1),
diff --git a/gcc/gimplify.c b/gcc/gimplify.c
index 99d1c7fcce4..8ee205f593c 100644
--- a/gcc/gimplify.c
+++ b/gcc/gimplify.c
@@ -2840,7 +2840,10 @@ gimplify_var_or_parm_decl (tree *expr_p)
declaration, for which we've already issued an error. It would
be really nice if the front end wouldn't leak these at all.
Currently the only known culprit is C++ destructors, as seen
- in g++.old-deja/g++.jason/binding.C. */
+ in g++.old-deja/g++.jason/binding.C.
+ Another possible culpit are size expressions for variably modified
+ types which are lost in the FE or not gimplified correctly.
+ */
if (VAR_P (decl)
&& !DECL_SEEN_IN_BIND_EXPR_P (decl)
&& !TREE_STATIC (decl) && !DECL_EXTERNAL (decl)
@@ -2985,16 +2988,22 @@ gimplify_compound_lval (tree *expr_p, gimple_seq
*pre_p, gimple_seq *post_p,
expression until we deal with any variable bounds, sizes, or
positions in order to deal with PLACEHOLDER_EXPRs.
- So we do this in three steps. First we deal with the annotations
- for any variables in the components, then we gimplify the base,
- then we gimplify any indices, from left to right. */
+ The base expression may contain a statement expression that
+ has declarations used in size expressions, so has to be
+ gimplified before gimplifying the size expressions.
+
+ So we do this in three steps. First we deal with variable
+ bounds, sizes, and positions, then we gimplify the base,
+ then we deal with the annotations for any variables in the
+ components and any indices, from left to right. */
+
for (i = expr_stack.length () - 1; i >= 0; i--)
{
tree t = expr_stack[i];
if (TREE_CODE (t) == ARRAY_REF || TREE_CODE (t) == ARRAY_RANGE_REF)
{
- /* Gimplify the low bound and element type size and put them into
+ /* Deal with the low bound and element type size and put them into
[PATCH v3] Fix ICE when mixing VLAs and statement expressions [PR91038]
Here is the third version of the patch. This also
fixes the index zero case. Thus, this should be
a complete fix for 91038 and should fix all cases
also supported by clang. Still not working is
returning a struct of variable size from a
statement expression (29970) when the size depends
on computations inside the statement expression.
Bootstrapped and regression tested
on x86-64 for all languages.
Martin
Fix ICE when mixing VLAs and statement expressions [PR91038]
When returning VM-types from statement expressions, this can
lead to an ICE when declarations from the statement expression
are referred to later. Most of these issues can be addressed by
gimplifying the base expression earlier in gimplify_compound_lval.
Another issue is fixed by not reording some size-related expressions
during folding. This fixes PR91038 and some of the test cases
from PR29970 (structs with VLA members need further work).
2021-08-01 Martin Uecker
gcc/
PR c/91038
PR c/29970
* gimplify.c (gimplify_var_or_parm_decl): Update comment.
(gimplify_compound_lval): Gimplify base expression first.
(gimplify_target_expr): Do not gimplify size expression.
* fold-const.c (fold_binary_loc): Do not reorder SAVE_EXPR
in pointer arithmetic for variably modified types.
gcc/testsuite/
PR c/91038
PR c/29970
* gcc.dg/vla-stexp-3.c: New test.
* gcc.dg/vla-stexp-4.c: New test.
* gcc.dg/vla-stexp-5.c: New test.
* gcc.dg/vla-stexp-6.c: New test.
* gcc.dg/vla-stexp-7.c: New test.
* gcc.dg/vla-stexp-8.c: New test.
* gcc.dg/vla-stexp-9.c: New test.
diff --git a/gcc/fold-const.c b/gcc/fold-const.c
index ff23f12f33c..1e6f50692b5 100644
--- a/gcc/fold-const.c
+++ b/gcc/fold-const.c
@@ -10854,7 +10854,15 @@ fold_binary_loc (location_t loc, enum tree_code code,
tree type,
return build2_loc (loc, COMPOUND_EXPR, type, TREE_OPERAND (arg0, 0),
tem);
}
- if (TREE_CODE (arg1) == COMPOUND_EXPR)
+ /* This interleaves execution of the two sub-expressions
+which is allowed in C. For pointer arithmetic when the
+the pointer has a variably modified type, the right expression
+might have a SAVE_EXPR which depends on the left expr, so
+do not fold in this case. */
+ if (TREE_CODE (arg1) == COMPOUND_EXPR
+ && !(code == POINTER_PLUS_EXPR
+ && TREE_CODE (TREE_OPERAND (arg1, 0)) == SAVE_EXPR)
+ && variably_modified_type_p (type, NULL_TREE))
{
tem = fold_build2_loc (loc, code, type, op0,
fold_convert_loc (loc, TREE_TYPE (op1),
diff --git a/gcc/gimplify.c b/gcc/gimplify.c
index 99d1c7fcce4..8ee205f593c 100644
--- a/gcc/gimplify.c
+++ b/gcc/gimplify.c
@@ -2840,7 +2840,10 @@ gimplify_var_or_parm_decl (tree *expr_p)
declaration, for which we've already issued an error. It would
be really nice if the front end wouldn't leak these at all.
Currently the only known culprit is C++ destructors, as seen
- in g++.old-deja/g++.jason/binding.C. */
+ in g++.old-deja/g++.jason/binding.C.
+ Another possible culpit are size expressions for variably modified
+ types which are lost in the FE or not gimplified correctly.
+ */
if (VAR_P (decl)
&& !DECL_SEEN_IN_BIND_EXPR_P (decl)
&& !TREE_STATIC (decl) && !DECL_EXTERNAL (decl)
@@ -2985,16 +2988,22 @@ gimplify_compound_lval (tree *expr_p, gimple_seq
*pre_p, gimple_seq *post_p,
expression until we deal with any variable bounds, sizes, or
positions in order to deal with PLACEHOLDER_EXPRs.
- So we do this in three steps. First we deal with the annotations
- for any variables in the components, then we gimplify the base,
- then we gimplify any indices, from left to right. */
+ The base expression may contain a statement expression that
+ has declarations used in size expressions, so has to be
+ gimplified before gimplifying the size expressions.
+
+ So we do this in three steps. First we deal with variable
+ bounds, sizes, and positions, then we gimplify the base,
+ then we deal with the annotations for any variables in the
+ components and any indices, from left to right. */
+
for (i = expr_stack.length () - 1; i >= 0; i--)
{
tree t = expr_stack[i];
if (TREE_CODE (t) == ARRAY_REF || TREE_CODE (t) == ARRAY_RANGE_REF)
{
- /* Gimplify the low bound and element type size and put them into
+ /* Deal with the low bound and element type size and put them into
the ARRAY_REF. If these values are set, they have already been
gimplified. */
if (TREE_OPERAND (t, 2) == NULL_TREE)
@@ -3003,18 +3012,8 @@ gimplify_compound_lval (tree *expr_p, gimple_seq *pre_p,
gimple_seq *post_p,
if (!is_gimple_min_invariant (low))
