[Bug c/17913] New: ICE jumping into statement expression

[Bug c/17913] New: ICE jumping into statement expression

[jsm28 at gcc dot gnu dot org]

The following code gives an ICE (no special compilation options needed):

void f(void) { 1 ? 1 : ({ a : 1; 1; }); goto a; }

t.c: In function 'f':
t.c:1: internal compiler error: virtual array label to block map[20]: element
4294967295 out of bounds in label_to_block, at /tree-cfg.c:622
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.

The ICE is a bug, which is a regression.  If this is to be permitted
then the real bug may be that we optimise the conditional expression
too early, though I think the proper fix is to reject jumping into
a constant expression (per bug 772) even if people have real code
that wants to jump *out* of them.

-- 
           Summary: ICE jumping into statement expression
           Product: gcc
           Version: 4.0.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: jsm28 at gcc dot gnu dot org
                CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17913

[Bug c/17913] [4.0 Regression] ICE jumping into statement expression

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-09 20:18 -------
Confirmed, the problem is that we removing ({ a : 1; 1; }); before generating the CFG so we don't have a 
BB containing 1.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2004-10-09 20:18:31
               date|                            |
            Summary|ICE jumping into statement  |[4.0 Regression] ICE jumping
                   |expression                  |into statement expression
   Target Milestone|---                         |4.0.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17913

[Bug c/17913] [4.0 Regression] ICE jumping into statement expression

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-14 03:47 -------
Yes we remove it because ({ a : 1; 1; }) is marked as no has SIDE_EFFECTS which fold changes 
COND_EXPR <true, true, ({ a : 1; 1; })>; to just true; which removes the label.

The ICE is a regression but before in both 3.1 and 3.3, we don't produce the local label at all, I have not 
tested 2.95.3 at all.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice-on-valid-code, wrong-
                   |                            |code


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17913

[Bug c/17913] [4.0 Regression] ICE jumping into statement expression

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-15 14:12 -------
I was wrong in the sense it is not fold that is removing it but build_conditional_expr is.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17913

[Bug c/17913] [4.0 Regression] ICE jumping into statement expression

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-15 14:21 -------
But if I remove the code in build_conditional_expr to fix the problem, we have the same problem in 
fold.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17913

[Bug c/17913] [4.0 Regression] ICE jumping into statement expression

[steven at gcc dot gnu dot org]

------- Additional Comments From steven at gcc dot gnu dot org  2004-10-27 12:25 -------
Surely this is not valid?

A statement expression is an _expression_ so any kind of control
flow into or out of a statement expression is just wrong IMHO.
It's like jumping into "a + b", try defining semantics for such
a construct.

Looking at the documentation as an indication of the intent of
this extension, it appears that control flow into and out of
statement expressions is not supposed to happen:

   "   A compound statement enclosed in parentheses may appear as an
   expression in GNU C.  This allows you to use loops, switches, and
   local variables within an expression."

Note, [various control structures] *within* an expression".
So statement expressions are still just expressions, and control
flow is supposed to be within the expression.  Jumping into or
out of statement expressions was apparently not intended to be
supported.

So I think this really should be a hard error.  



-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |loki at inf dot u-szeged dot
                   |                            |hu
   Last reconfirmed|2004-10-09 20:18:31         |2004-10-27 12:25:14
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17913

[Bug c/17913] [4.0 Regression] ICE jumping into statement expression

[steven at gcc dot gnu dot org]

------- Additional Comments From steven at gcc dot gnu dot org  2004-10-27 12:42 -------
Proposed patch here.
http://gcc.gnu.org/ml/gcc-patches/2004-10/msg02304.html

Part of the discussion here (broken mailer :-/)
http://gcc.gnu.org/ml/gcc-patches/2004-10/msg02310.html

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17913

[Bug c/17913] [4.0 Regression] ICE jumping into statement expression

[jsm at polyomino dot org dot uk]

------- Additional Comments From jsm at polyomino dot org dot uk  2004-10-27 12:55 -------
Subject: Re:  [4.0 Regression] ICE jumping into statement
 expression

On Wed, 27 Oct 2004, steven at gcc dot gnu dot org wrote:

> Surely this is not valid?

The validity is the subject of bug 772 and the long thread linked from 
there.  This bug is for a particular ICE which is a regression; whether 
the code is valid or invalid depends on whether any resolution suggested 
in bug 772 or elsewhere is adopted.

I haven't seen a use for jumps into statement expressions and think we 
should disallow them.  This isn't as simple as making the labels local to 
the statement expression.  First, you need to check for switch statements 
jumping into the statement expression.  Second, if inside a statement 
expression you encounter a reference to an undeclared label, you don't 
know whether it refers to one later within that statement expression or 
one outside in the function (and in an address-of-label context, both 
could reasonably be valid) so don't know in what scope to declare the 
label (or, if there's one outside already seen with that name, whether the 
new one is a reference to that label or to a new local one).  For that 
reason I think it's best to keep the current scoping rules and have a 
separate check for any form of jumps into statement expressions, with 
jumps by computed goto explicitly runtime undefined.  (While jumps in from 
longjmp might be OK.)

Jumps out of statement expressions are or were used in real code 
<http://gcc.gnu.org/ml/gcc-patches/2003-05/msg00770.html>.  I don't think 
they are well-defined (except for jumps using longjmp), but I believe we 
need a deprecation period before removing them (e.g. deprecate in 4.0, 
remove in 4.1).



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17913

[Bug c/17913] [4.0 Regression] ICE jumping into statement expression

[loki at inf dot u-szeged dot hu]

------- Additional Comments From loki at inf dot u-szeged dot hu  2004-10-28 06:42 -------
(In reply to comment #7)
> > Surely this is not valid?
> 
> The validity is the subject of bug 772 and the long thread linked from 
> there.  This bug is for a particular ICE which is a regression; whether 
> the code is valid or invalid depends on whether any resolution suggested 
> in bug 772 or elsewhere is adopted.

Yes. I agree with you. This is a regression in ?: operator evaluation. I didn't
want to change anything about bug 772.

[...]
> First, you need to check for switch statements 
> jumping into the statement expression.  Second, if inside a statement 
> expression you encounter a reference to an undeclared label, you don't 
> know whether it refers to one later within that statement expression or 
> one outside in the function (and in an address-of-label context, both 
> could reasonably be valid) so don't know in what scope to declare the 
> label (or, if there's one outside already seen with that name, whether the 
> new one is a reference to that label or to a new local one).  For that 
> reason I think it's best to keep the current scoping rules and have a 
> separate check for any form of jumps into statement expressions, with 
> jumps by computed goto explicitly runtime undefined.  (While jumps in from 
> longjmp might be OK.)

Yes, you are right. I missed some cases. I'm working on it...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17913

[Bug c/17913] [4.0 Regression] ICE jumping into statement expression

[bonzini at gcc dot gnu dot org]

------- Additional Comments From bonzini at gcc dot gnu dot org  2004-10-28 13:30 -------
> Jumps out of statement expressions are or were used in real code 
> <http://gcc.gnu.org/ml/gcc-patches/2003-05/msg00770.html>.  I don't think 
> they are well-defined (except for jumps using longjmp), but I believe we 
> need a deprecation period before removing them (e.g. deprecate in 4.0, 
> remove in 4.1).

I remember using once a void statement expression "((void) ({ ... })" instead of
"do ... while (0)" in macros.  It had something to do with emulated recursion,
so I wanted to use "continue" inside the macro to do the recursion.  The
emulated recursive calls were ten or so in that function, hence using macros.

I had tried "if (1) ... else" as well, but then GCC gave warnings about possible
dangling "else"s.

Paolo

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17913

[Bug c/17913] [4.0 Regression] ICE jumping into statement expression

[jsm at polyomino dot org dot uk]

------- Additional Comments From jsm at polyomino dot org dot uk  2004-10-28 15:05 -------
Subject: Re:  [4.0 Regression] ICE jumping into statement
 expression

On Thu, 28 Oct 2004, bonzini at gcc dot gnu dot org wrote:

> I remember using once a void statement expression "((void) ({ ... })" instead of
> "do ... while (0)" in macros.  It had something to do with emulated recursion,
> so I wanted to use "continue" inside the macro to do the recursion.  The
> emulated recursive calls were ten or so in that function, hence using macros.

So we have another example of jumps out being used.  That doesn't mean we 
want to support them - and certainly doesn't mean we can define sensibly 
what they mean when the statement expression isn't the full expression 
statement - but affirms that if we stop allowing jumps out then we need a 
deprecation period.

Whereas jumps in we can reasonably declare invalid, fix that part of bug 
772 by putting in an error for jumping in and hopefully fix this 
ice-on-invalid as well, without a deprecation period.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17913

[Bug c/17913] [4.0 Regression] ICE jumping into statement expression

[loki at inf dot u-szeged dot hu]

------- Additional Comments From loki at inf dot u-szeged dot hu  2004-11-03 08:17 -------
I made some changes in the patch. I hope that it will be satisfying.
http://gcc.gnu.org/ml/gcc-patches/2004-11/msg00130.html


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17913

[Bug c/17913] [4.0 Regression] ICE jumping into statement expression

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-20 04:15 -------
Note with --disable-checking I still get an ICE but this time a seg fault.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17913

[Bug c/17913] [4.0/4.1 Regression] ICE jumping into statement expression

[mmitchel at gcc dot gnu dot org]

------- Additional Comments From mmitchel at gcc dot gnu dot org  2005-03-24 18:22 -------
Joseph, do you think it is tractable and reasonable to diagnose jumps into
statement expressions for 4.0?  If you and RTH agree that this should be
invalid, then that would be ideal.  If you agree that this should be invalid,
but don't think it's possible to fix, would you please adjust the Keywords entry
here, so that this is not marked as a wrong-code/ice-on-valid-code regression,
but rather accepts-invalid?

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17913

[Bug c/17913] [4.0/4.1 Regression] ICE jumping into statement expression

[joseph at codesourcery dot com]

------- Additional Comments From joseph at codesourcery dot com  2005-03-24 20:34 -------
Subject: Re:  [4.0/4.1 Regression] ICE jumping into statement
 expression

On Thu, 24 Mar 2005, mmitchel at gcc dot gnu dot org wrote:

> Joseph, do you think it is tractable and reasonable to diagnose jumps into
> statement expressions for 4.0?  If you and RTH agree that this should be
> invalid, then that would be ideal.  If you agree that this should be invalid,
> but don't think it's possible to fix, would you please adjust the Keywords entry
> here, so that this is not marked as a wrong-code/ice-on-valid-code regression,
> but rather accepts-invalid?

I think it is tractable and reasonable to diagnose jumps into statement 
expressions (at least for C, not having looked at the implementation for 
C++) for 4.0.  I also don't see anything *wrong* with the C front end 
changes in the patch posted for this bug, given that the rest of the patch 
could still be of use if there are front ends which want to continue to 
allow jumps into conditional expressions which might otherwise get folded.  
(And in abstract there's nothing wrong with a front end trying to fold a 
COND_EXPR arising from if (0) { ... } else { ... }, which certainly can be 
jumped into; just that in practice trying to fold such a tree is unlikely 
to be useful.)

Having spent an hour working out how to diagnose jumps into statement 
expressions I've arrived at the following approach which I'd try; I expect 
something similar would work for C++ as well:

* Add three flags to labels: one for "this label was in a statement 
expression which has finished, so you can't jump to it any more", one for 
"this label has a goto jumping to it from the current level of statement 
expression nesting" and one for "this label has a goto jumping to it from 
outside the current level of statement expression nesting".

* Keep a list at each level of statement expression nesting (including 
inside a function but outside all statement expressions) of all labels 
defined at that level, and a list of all labels with gotos to them at that 
level.

* When a goto is encountered, it mustn't be to a label with the first 
flag.  Otherwise, if it doesn't have the second or third flag, give it the 
second flag and put it on the current list of gotos.

* When a label is defined, it mustn't have the third flag.  Otherwise, put 
it on the list of labels defined at that level.

* When starting a statement expression, start new lists as above.  Given 
all labels on the immediately previous list of gotos the third flag (so 
they can't be defined until that statement expression ends).

* When ending a statement expression, give all labels defined in that 
expression the first flag.  Remove the third flag from all gotos in the 
level to which we are returning, leaving the second flag on them.  Move 
the gotos in the list of the level we are leaving to the list of the level 
which we are returning (and leave the second flag on them).

* Keep a flag for whether the current switch statement started outside 
the current statement expression.  When starting a statement expression, 
save the flag's value and set it to true; restore it when ending a 
statement expression.  When starting a switch statement, save the flag's 
value and set it to false; restore it when ending a switch statement.  Do 
not allow case or default labels when the flag is true.

* Generate a testcase involving all cases of a function with two statement 
expressions inside, each of those containing two statement expressions and 
the label and goto in all possible places, i.e.

void
f (void)
{
 ^({ ^({^0;}); ^({^0;}); ^0;});
 ^({ ^({^0;}); ^({^0;}); ^0;});
 ^0;^
}

with the goto at any place marked ^ and the label on the goto or at any of 
those places other than right at the end of the function, i.e. 196 such 
functions, making sure that the correct subset are rejected.  (This is 
operating on the basis that we will continue to allow jumps *out* of 
statement expressions, as people have real uses for such, with it simply 
being unspecified which collateral expressions of the statement expression 
(subexpressions of the larger expression containing the statement 
expression not separated from it by a sequence point, e.g. foo() in foo() 
+ ({ goto a; 0; })) have been evaluated.)

(The second flag on labels is only used to avoid listing labels more than 
once at the same level of nesting; it isn't strictly required, and 
actually implementing it would mean multipurposing another one of the 
DECL_LANG_FLAG fields: C is using 0-5 with 4 already multipurposed.)



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17913

[Bug c/17913] [4.0/4.1 Regression] ICE jumping into statement expression

[jsm28 at gcc dot gnu dot org]

------- Additional Comments From jsm28 at gcc dot gnu dot org  2005-03-30 18:08 -------
Patch at <http://gcc.gnu.org/ml/gcc-patches/2005-03/msg02668.html> addresses
the issue for C and noncomputed gotos by disallowing such jumps; awaiting
any comments on the proposed statement expression semantics.  Does not address
the issue for C++ which needs similar changes, and the possibility of computed
gotos means that something like
<http://gcc.gnu.org/ml/gcc-patches/2004-11/msg00130.html> but adjusted as
described in that message is needed as well.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17913

[Bug c/17913] [4.0/4.1 Regression] ICE jumping into statement expression

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-03-30 19:56 -------
Subject: Bug 17913

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	jsm28@gcc.gnu.org	2005-03-30 19:56:40

Modified files:
	gcc            : ChangeLog c-decl.c c-tree.h c-typeck.c 
	gcc/doc        : extend.texi 
	gcc/objc       : ChangeLog objc-act.c 
	gcc/testsuite  : ChangeLog 
Added files:
	gcc/testsuite/gcc.dg: stmt-expr-label-1.c stmt-expr-label-2.c 
	                      stmt-expr-label-3.c 
Removed files:
	gcc/testsuite/gcc.c-torture/execute: medce-2.c 

Log message:
	PR c/772
	PR c/17913
	* c-tree.h (C_DECL_UNJUMPABLE_STMT_EXPR,
	C_DECL_UNDEFINABLE_STMT_EXPR, struct c_label_list, struct
	c_label_context, label_context_stack): New.
	* c-decl.c (define_label): Check for jumps into statement
	expressions.  Add label to list of defined labels.
	(start_function): Push context on label_context_stack.
	(finish_function): Pop context from label_context_stack.
	* c-typeck.c (label_context_stack): New.
	(c_finish_goto_label): Check for jumps into statement
	expressions.  Add label to list of jumped to labels.
	(struct c_switch): Add blocked_stmt_expr.
	(c_start_case): Initialize it.
	(do_case): Check it.
	(c_finish_case): Verify !blocked_stmt_expr.
	(c_begin_stmt_expr):  Push context on label_context_stack.
	Increment blocked_stmt_expr.  Mark labels jumped to from outside
	as undefinable.
	(c_finish_stmt_expr): December blocked_stmt_expr.  Mark labels
	defined in the statement expression and no longer jumpable to.
	Mark labels jumped to from just outside the statement expression
	as again definable.  Pop context from label_context_stack.
	* doc/extend.texi (Statement Exprs): Update.
	
	objc:
	* objc-act.c (objc_start_function): Push context on
	label_context_stack.
	
	testsuite:
	* gcc.dg/stmt-expr-label-1.c, gcc.dg/stmt-expr-label-2.c,
	gcc.dg/stmt-expr-label-3.c : New tests.
	* gcc.c-torture/execute/medce-2.c: Remove.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8036&r2=2.8037
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-decl.c.diff?cvsroot=gcc&r1=1.642&r2=1.643
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-tree.h.diff?cvsroot=gcc&r1=1.198&r2=1.199
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-typeck.c.diff?cvsroot=gcc&r1=1.428&r2=1.429
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/doc/extend.texi.diff?cvsroot=gcc&r1=1.246&r2=1.247
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/objc/ChangeLog.diff?cvsroot=gcc&r1=1.31&r2=1.32
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/objc/objc-act.c.diff?cvsroot=gcc&r1=1.267&r2=1.268
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5237&r2=1.5238
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/execute/medce-2.c.diff?cvsroot=gcc&r1=1.1&r2=NONE
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/stmt-expr-label-1.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/stmt-expr-label-2.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/stmt-expr-label-3.c.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17913

[Bug c/17913] [4.0/4.1 Regression] ICE jumping into statement expression

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-03-30 19:59 -------
Subject: Bug 17913

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	gcc-4_0-branch
Changes by:	jsm28@gcc.gnu.org	2005-03-30 19:59:21

Modified files:
	gcc            : ChangeLog c-decl.c c-tree.h c-typeck.c 
	gcc/doc        : extend.texi 
	gcc/objc       : ChangeLog objc-act.c 
	gcc/testsuite  : ChangeLog 
Added files:
	gcc/testsuite/gcc.dg: stmt-expr-label-1.c stmt-expr-label-2.c 
	                      stmt-expr-label-3.c 
Removed files:
	gcc/testsuite/gcc.c-torture/execute: medce-2.c 

Log message:
	PR c/772
	PR c/17913
	* c-tree.h (C_DECL_UNJUMPABLE_STMT_EXPR,
	C_DECL_UNDEFINABLE_STMT_EXPR, struct c_label_list, struct
	c_label_context, label_context_stack): New.
	* c-decl.c (define_label): Check for jumps into statement
	expressions.  Add label to list of defined labels.
	(start_function): Push context on label_context_stack.
	(finish_function): Pop context from label_context_stack.
	* c-typeck.c (label_context_stack): New.
	(c_finish_goto_label): Check for jumps into statement
	expressions.  Add label to list of jumped to labels.
	(struct c_switch): Add blocked_stmt_expr.
	(c_start_case): Initialize it.
	(do_case): Check it.
	(c_finish_case): Verify !blocked_stmt_expr.
	(c_begin_stmt_expr):  Push context on label_context_stack.
	Increment blocked_stmt_expr.  Mark labels jumped to from outside
	as undefinable.
	(c_finish_stmt_expr): December blocked_stmt_expr.  Mark labels
	defined in the statement expression and no longer jumpable to.
	Mark labels jumped to from just outside the statement expression
	as again definable.  Pop context from label_context_stack.
	* doc/extend.texi (Statement Exprs): Update.
	
	objc:
	* objc-act.c (objc_start_function): Push context on
	label_context_stack.
	
	testsuite:
	* gcc.dg/stmt-expr-label-1.c, gcc.dg/stmt-expr-label-2.c,
	gcc.dg/stmt-expr-label-3.c : New tests.
	* gcc.c-torture/execute/medce-2.c: Remove.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.97&r2=2.7592.2.98
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-decl.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.630.6.3&r2=1.630.6.4
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-tree.h.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.193.4.1&r2=1.193.4.2
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-typeck.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.419&r2=1.419.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/doc/extend.texi.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.240.2.5&r2=1.240.2.6
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/objc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.29&r2=1.29.8.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/objc/objc-act.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.266&r2=1.266.6.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.80&r2=1.5084.2.81
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/execute/medce-2.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.1&r2=NONE
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/stmt-expr-label-1.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/stmt-expr-label-2.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/stmt-expr-label-3.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17913

[Bug c/17913] [4.0/4.1 Regression] ICE jumping into statement expression

[mmitchel at gcc dot gnu dot org]

------- Additional Comments From mmitchel at gcc dot gnu dot org  2005-04-17 03:51 -------
Joseph has mititgated the problem, and we shan't be doing any further work on
this before 4.0.0.  So, I have pushed the target milestone back to 4.0.1.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.0.0                       |4.0.1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17913

[Bug c/17913] [4.0/4.1 Regression] ICE jumping into statement expression

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-10 13:47 -------
Subject: Bug 17913

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	loki@gcc.gnu.org	2005-05-10 13:47:05

Modified files:
	gcc            : ChangeLog c-typeck.c fold-const.c 
	gcc/testsuite  : ChangeLog 
Added files:
	gcc/testsuite/gcc.c-torture/compile: pr17913.c 

Log message:
	2005-05-10  Gabor Loki <loki@gcc.gnu.org>
	
	PR c/17913
	* c-typeck.c (build_conditional_expr): Remove reducing cond_expr.
	* fold-const.c (fold): Expand the condition of reducing cond_expr.
	(contains_label_1, contains_label_p): New functions for checking
	labels in a sub-tree.
	
	testsuite:
	2005-05-10  Gabor Loki <loki@gcc.gnu.org>
	
	PR c/17913
	* gcc.c-torture/compile/pr17913.c: Computed jump test for PR17913

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8704&r2=2.8705
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-typeck.c.diff?cvsroot=gcc&r1=1.440&r2=1.441
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fold-const.c.diff?cvsroot=gcc&r1=1.574&r2=1.575
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5455&r2=1.5456
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/compile/pr17913.c.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17913

[Bug c/17913] [4.0/4.1 Regression] ICE jumping into statement expression

[loki at gcc dot gnu dot org]

------- Additional Comments From loki at gcc dot gnu dot org  2005-05-10 13:50 -------
CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	loki@gcc.gnu.org	2005-05-10 13:47:05

Modified files:
	gcc            : ChangeLog c-typeck.c fold-const.c 
	gcc/testsuite  : ChangeLog 
Added files:
	gcc/testsuite/gcc.c-torture/compile: pr17913.c 

Log message:
	2005-05-10  Gabor Loki <loki@gcc.gnu.org>
	
	PR c/17913
	* c-typeck.c (build_conditional_expr): Remove reducing cond_expr.
	* fold-const.c (fold): Expand the condition of reducing cond_expr.
	(contains_label_1, contains_label_p): New functions for checking
	labels in a sub-tree.
	
	testsuite:
	2005-05-10  Gabor Loki <loki@gcc.gnu.org>
	
	PR c/17913
	* gcc.c-torture/compile/pr17913.c: Computed jump test for PR17913

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8704&r2=2.8705
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-typeck.c.diff?cvsroot=gcc&r1=1.440&r2=1.441
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fold-const.c.diff?cvsroot=gcc&r1=1.574&r2=1.575
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5455&r2=1.5456
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/compile/pr17913.c.diff?cvsroot=gcc&r1=NONE&r2=1.1


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17913

[Bug c/17913] [4.0 Regression] ICE jumping into statement expression

[mmitchel at gcc dot gnu dot org]

------- Additional Comments From mmitchel at gcc dot gnu dot org  2005-07-06 16:48 -------
Postponed until 4.0.2.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.0.1                       |4.0.2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17913

[Bug c++/17913] [4.0 Regression] ICE jumping into statement expression

[rguenth at gcc dot gnu dot org]

------- Additional Comments From rguenth at gcc dot gnu dot org  2005-09-09 10:41 -------
This is fixed in the C frontend.  C++ needs taking care (4.1 works).  By the
solution for the C frontend problem I suppose this is now ice-on-invalid-code.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c                           |c++
           Keywords|ice-on-valid-code           |ice-on-invalid-code
      Known to fail|                            |4.0.1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17913

[Bug c++/17913] [4.0 Regression] ICE jumping into statement expression

[mmitchel at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.0.2                       |4.0.3


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17913