[Bug tree-optimization/34005] [4.3 Regression] ICE: verify_ssa failed (expected an SSA_NAME object)
--- Comment #16 from jakub at gcc dot gnu dot org 2007-12-06 10:07 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34005
[Bug tree-optimization/34005] [4.3 Regression] ICE: verify_ssa failed (expected an SSA_NAME object)
--- Comment #15 from jakub at gcc dot gnu dot org 2007-12-06 10:06 --- Subject: Bug 34005 Author: jakub Date: Thu Dec 6 10:06:38 2007 New Revision: 130647 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130647 Log: 2007-12-06 Zdenek Dvorak <[EMAIL PROTECTED]> Dorit Nuzman <[EMAIL PROTECTED]> Jakub Jelinek <[EMAIL PROTECTED]> PR tree-optimization/34005 * tree-gimple.c (is_gimple_formal_tmp_rhs): Add a case for COND_EXPR. * gimplify.c (gimplify_ctx): Add a new member allow_rhs_cond_expr. (gimplify_pure_cond_expr): New function. (generic_expr_could_trap_p): New function. (gimplify_cond_expr): Call gimplify_pure_cond_expr. (force_gimple_operand): Initialize new field allow_rhs_cond_expr. 2007-12-06 Martin Michlmayr <[EMAIL PROTECTED]> Dorit Nuzman <[EMAIL PROTECTED]> PR tree-optimization/34005 * gcc.dg/vect/pr34005.c: New test. Added: trunk/gcc/testsuite/gcc.dg/vect/pr34005.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-gimple.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34005
[Bug tree-optimization/34005] [4.3 Regression] ICE: verify_ssa failed (expected an SSA_NAME object)
--- Comment #14 from jakub at gcc dot gnu dot org 2007-12-04 08:11 --- *** Bug 34329 has been marked as a duplicate of this bug. *** -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||christophe at saout dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34005
[Bug tree-optimization/34005] [4.3 Regression] ICE: verify_ssa failed (expected an SSA_NAME object)
--- Comment #13 from rakdver at kam dot mff dot cuni dot cz 2007-11-28 13:45 --- Subject: Re: [4.3 Regression] ICE: verify_ssa failed (expected an SSA_NAME object) > --- Comment #12 from jakub at gcc dot gnu dot org 2007-11-28 13:20 > --- > So, shouldn't the expression_without_side_effects_p routine just be renamed > to expression_could_trap_p, otherwise it will be confused again and again with > !TREE_SIDE_EFFECTS on the expr? The gimplify_cond_expr new hunk then could be > + if (gimplify_ctxp->allow_rhs_cond_expr > + /* If either branch has side effects or could trap, it can't be > + evaluated unconditionally. */ > + && !TREE_SIDE_EFFECTS (TREE_OPERAND (*expr_p, 1)) > + && !expression_could_trap_p (TREE_OPERAND (*expr_p, 1)) > + && !TREE_SIDE_EFFECTS (TREE_OPERAND (*expr_p, 2)) > + && !expression_could_trap_p (TREE_OPERAND (*expr_p, 2))) > + return gimplify_pure_cond_expr (expr_p, pre_p); > > This would allow side effects on condition of the COND_EXPR, and at least to > me > would be less confusing (and given that Diego raised that question first, I'm > probably not alone). that would be fine with me (it would be safer than changing the semantics of TREE_SIDE_EFFECTS). I guess it is up to Diego, I am willing to do it either way. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34005
[Bug tree-optimization/34005] [4.3 Regression] ICE: verify_ssa failed (expected an SSA_NAME object)
--- Comment #12 from jakub at gcc dot gnu dot org 2007-11-28 13:20 --- So, shouldn't the expression_without_side_effects_p routine just be renamed to expression_could_trap_p, otherwise it will be confused again and again with !TREE_SIDE_EFFECTS on the expr? The gimplify_cond_expr new hunk then could be + if (gimplify_ctxp->allow_rhs_cond_expr + /* If either branch has side effects or could trap, it can't be + evaluated unconditionally. */ + && !TREE_SIDE_EFFECTS (TREE_OPERAND (*expr_p, 1)) + && !expression_could_trap_p (TREE_OPERAND (*expr_p, 1)) + && !TREE_SIDE_EFFECTS (TREE_OPERAND (*expr_p, 2)) + && !expression_could_trap_p (TREE_OPERAND (*expr_p, 2))) + return gimplify_pure_cond_expr (expr_p, pre_p); This would allow side effects on condition of the COND_EXPR, and at least to me would be less confusing (and given that Diego raised that question first, I'm probably not alone). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34005
[Bug tree-optimization/34005] [4.3 Regression] ICE: verify_ssa failed (expected an SSA_NAME object)
--- Comment #11 from rakdver at kam dot mff dot cuni dot cz 2007-11-27 16:44 --- Subject: Re: [4.3 Regression] ICE: verify_ssa failed (expected an SSA_NAME object) > And for 2nd and 3rd argument wouldn't it for loop and vectorizer be sufficient > to just test is_gimple_val? I.e. > if (gimplify_ctxp->allow_rhs_cond_expr > && is_gimple_val (TREE_OPERAND (*expr_p, 1)) > && is_gimple_val (TREE_OPERAND (*expr_p, 2))) > return gimplify_pure_cond_expr (expr_p, pre_p); no, the number of iterations may be an expression. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34005
[Bug tree-optimization/34005] [4.3 Regression] ICE: verify_ssa failed (expected an SSA_NAME object)
--- Comment #10 from jakub at gcc dot gnu dot org 2007-11-27 16:37 --- I see. Though you probably shouldn't care about side effects in the first argument of COND_EXPR, that's going to be evaluated in any case. And for 2nd and 3rd argument wouldn't it for loop and vectorizer be sufficient to just test is_gimple_val? I.e. if (gimplify_ctxp->allow_rhs_cond_expr && is_gimple_val (TREE_OPERAND (*expr_p, 1)) && is_gimple_val (TREE_OPERAND (*expr_p, 2))) return gimplify_pure_cond_expr (expr_p, pre_p); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34005
[Bug tree-optimization/34005] [4.3 Regression] ICE: verify_ssa failed (expected an SSA_NAME object)
--- Comment #9 from rakdver at kam dot mff dot cuni dot cz 2007-11-27 16:03 --- Subject: Re: [4.3 Regression] ICE: verify_ssa failed (expected an SSA_NAME object) > > I think the problems only appeared if allow_rhs_cond_expr was enabled > > for the gimplification pass (when called from the loop optimizer, > > the expressions passed to gimplifier do not have any side effects, > > so you would not detect any problem even if you removed the > > TREE_SIDE_EFFECTS check). > > Even then, what failure was it? gimplify_pure_cond_expr gimplifies all the > 3 arguments anyway, so if they have side-effects, they just end up being > evaluated into temporaries which are then used in the COND_EXPR. however, you would get side effects of both branches evaluated that way. In particular, you get into problems for constructions like p == NULL ? 0 : *p -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34005
[Bug tree-optimization/34005] [4.3 Regression] ICE: verify_ssa failed (expected an SSA_NAME object)
--- Comment #8 from jakub at redhat dot com 2007-11-27 15:59 --- Subject: Re: [4.3 Regression] ICE: verify_ssa failed (expected an SSA_NAME object) > I think the problems only appeared if allow_rhs_cond_expr was enabled > for the gimplification pass (when called from the loop optimizer, > the expressions passed to gimplifier do not have any side effects, > so you would not detect any problem even if you removed the > TREE_SIDE_EFFECTS check). Even then, what failure was it? gimplify_pure_cond_expr gimplifies all the 3 arguments anyway, so if they have side-effects, they just end up being evaluated into temporaries which are then used in the COND_EXPR. Anyway, can you please follow up to Diego's mail, either agree to remove that, or justify it? Apart from a typo in ChangeLog entry that was his only objection and it would be good to have this P1 fixed ASAP. > yes, although making it work that way is more complicated; it would require > changes in the # of iterations analysis, to get Ok. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34005
[Bug tree-optimization/34005] [4.3 Regression] ICE: verify_ssa failed (expected an SSA_NAME object)
--- Comment #7 from rakdver at kam dot mff dot cuni dot cz 2007-11-27
15:04 ---
Subject: Re: [4.3 Regression] ICE: verify_ssa failed (expected an SSA_NAME
object)
> --- Comment #6 from jakub at gcc dot gnu dot org 2007-11-27 14:17 ---
> I've changed that
> + if (gimplify_ctxp->allow_rhs_cond_expr
> + && !TREE_SIDE_EFFECTS (*expr_p)
> + && expression_without_side_effects_p (*expr_p))
> + return gimplify_pure_cond_expr (expr_p, pre_p);
> into
> + if (gimplify_ctxp->allow_rhs_cond_expr
> + && !TREE_SIDE_EFFECTS (*expr_p))
> + {
> + gcc_assert (expression_without_side_effects_p (*expr_p));
> + return gimplify_pure_cond_expr (expr_p, pre_p);
> + }
> and so far haven't found any failure, so perhaps recalculate_side_effects
> wouldn't be needed. Or, was there any specific reason why TREE_SIDE_EFFECTS
> wasn't enough or was incorrect?
I think the problems only appeared if allow_rhs_cond_expr was enabled
for the gimplification pass (when called from the loop optimizer,
the expressions passed to gimplifier do not have any side effects,
so you would not detect any problem even if you removed the
TREE_SIDE_EFFECTS check).
> BTW, regarding the original rationale of the patch, to represent the number of
> iterations of a do ... while loop you could use also MAX_EXPR <1, n> and
> that's
> gimple already accepted by force_gimple_operand even without the patch.
yes, although making it work that way is more complicated; it would require
changes in the # of iterations analysis, to get
1000 + (unsigned) MAX_EXPR (-1000, n)
for
for (i = -1000; i < n; i++)
while we already have all the information necessary to produce
n >= -1000 ? 1000 + (unsigned) n : 0
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34005
[Bug tree-optimization/34005] [4.3 Regression] ICE: verify_ssa failed (expected an SSA_NAME object)
--- Comment #6 from jakub at gcc dot gnu dot org 2007-11-27 14:17 ---
I've changed that
+ if (gimplify_ctxp->allow_rhs_cond_expr
+ && !TREE_SIDE_EFFECTS (*expr_p)
+ && expression_without_side_effects_p (*expr_p))
+ return gimplify_pure_cond_expr (expr_p, pre_p);
into
+ if (gimplify_ctxp->allow_rhs_cond_expr
+ && !TREE_SIDE_EFFECTS (*expr_p))
+ {
+ gcc_assert (expression_without_side_effects_p (*expr_p));
+ return gimplify_pure_cond_expr (expr_p, pre_p);
+ }
and so far haven't found any failure, so perhaps recalculate_side_effects
wouldn't be needed. Or, was there any specific reason why TREE_SIDE_EFFECTS
wasn't enough or was incorrect?
BTW, regarding the original rationale of the patch, to represent the number of
iterations of a do ... while loop you could use also MAX_EXPR <1, n> and that's
gimple already accepted by force_gimple_operand even without the patch.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
CC||dorit at gcc dot gnu dot
||org, rakdver at gcc dot gnu
||dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34005
[Bug tree-optimization/34005] [4.3 Regression] ICE: verify_ssa failed (expected an SSA_NAME object)
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34005
[Bug tree-optimization/34005] [4.3 Regression] ICE: verify_ssa failed (expected an SSA_NAME object)
--- Comment #5 from tbm at cyrius dot com 2007-11-21 22:08 --- Note that Diego had some questions about the patch: http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00860.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34005
[Bug tree-optimization/34005] [4.3 Regression] ICE: verify_ssa failed (expected an SSA_NAME object)
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34005
[Bug tree-optimization/34005] [4.3 Regression] ICE: verify_ssa failed (expected an SSA_NAME object)
--- Comment #4 from dorit at gcc dot gnu dot org 2007-11-06 18:29 --- > We probably need to call the gimplifier (if we don't already) and also apply > Zdenek's patch that allows gimplifying rhs cond_exprs - > http://gcc.gnu.org/ml/gcc-patches/2007-07/msg02052.html. Yep - I just tried applying Zdenek's patch to the gimplifier, and it indeed solves the ICE in both tests. I'll go back and propose this patch for mainline again. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34005
[Bug tree-optimization/34005] [4.3 Regression] ICE: verify_ssa failed (expected an SSA_NAME object)
--- Comment #3 from dorit at gcc dot gnu dot org 2007-11-06 18:11 --- I don't think these are related to PR33680. Sounds like we may be generating a stmt with a cond_expr at the rhs. The data-reference analysis results in: base_address: &blocks offset from base address: k_4(D) == 0 ? 8 : 0 constant offset from base address: 0 step: 1 aligned to: 8 base_object: blocks[0][0] symbol tag: blocks (Note the cond_expr used to represent the offset). We probably need to call the gimplifier (if we don't already) and also apply Zdenek's patch that allows gimplifying rhs cond_exprs - http://gcc.gnu.org/ml/gcc-patches/2007-07/msg02052.html. -- dorit at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-11-06 18:11:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34005
[Bug tree-optimization/34005] [4.3 Regression] ICE: verify_ssa failed (expected an SSA_NAME object)
--- Comment #2 from tbm at cyrius dot com 2007-11-06 15:52 ---
When I change the testcase slightly I get a difference ICE:
[EMAIL PROTECTED]:~$ /usr/lib/gcc-snapshot/bin/gcc -c -O2 -ftree-vectorize
vnc-Unwrap2.c
vnc-Unwrap2.c: In function 'XdmcpUnwrap':
vnc-Unwrap2.c:4: error: control flow in the middle of basic block 3
vnc-Unwrap2.c:4: error: control flow in the middle of basic block 3
vnc-Unwrap2.c:4: error: control flow in the middle of basic block 3
vnc-Unwrap2.c:4: error: control flow in the middle of basic block 3
vnc-Unwrap2.c:4: error: control flow in the middle of basic block 3
vnc-Unwrap2.c:4: error: control flow in the middle of basic block 3
vnc-Unwrap2.c:4: internal compiler error: verify_flow_info failed
/* Testcase by Martin Michlmayr <[EMAIL PROTECTED]> */
void XdmcpUnwrap (unsigned char *output, int k)
{
int i;
unsigned char blocks[2][8];
k = (k == 0) ? 1 : 0;
for (i = 0; i < 8; i++)
output[i] = blocks[k][i];
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34005
[Bug tree-optimization/34005] [4.3 Regression] ICE: verify_ssa failed (expected an SSA_NAME object)
--- Comment #1 from tbm at cyrius dot com 2007-11-06 15:52 ---
/* Testcase by Martin Michlmayr <[EMAIL PROTECTED]> */
void XdmcpUnwrap (unsigned char *input, unsigned char *output, int k)
{
int i;
unsigned char blocks[8][8];
for (i = 0; i < 8; i++)
blocks[k][i] = input[i];
k = (k == 0) ? 1 : 0;
for (i = 0; i < 8; i++)
output[i] = blocks[k][i];
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34005
