* [Bug middle-end/42512] [4.5 Regression] integer wrong code bug with loop
2009-12-26 19:27 [Bug c/42512] New: possible integer wrong code bug regehr at cs dot utah dot edu
@ 2009-12-26 20:00 ` jakub at gcc dot gnu dot org
2009-12-26 22:13 ` hjl dot tools at gmail dot com
` (12 subsequent siblings)
13 siblings, 0 replies; 17+ messages in thread
From: jakub at gcc dot gnu dot org @ 2009-12-26 20:00 UTC (permalink / raw)
To: gcc-bugs
------- Comment #1 from jakub at gcc dot gnu dot org 2009-12-26 20:00 -------
This breaks during ivopts.
--
jakub at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Priority|P3 |P1
Last reconfirmed|0000-00-00 00:00:00 |2009-12-26 20:00:19
date| |
Summary|integer wrong code bug with |[4.5 Regression] integer
|loop |wrong code bug with loop
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42512
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug middle-end/42512] [4.5 Regression] integer wrong code bug with loop
2009-12-26 19:27 [Bug c/42512] New: possible integer wrong code bug regehr at cs dot utah dot edu
2009-12-26 20:00 ` [Bug middle-end/42512] [4.5 Regression] integer wrong code bug with loop jakub at gcc dot gnu dot org
@ 2009-12-26 22:13 ` hjl dot tools at gmail dot com
2009-12-26 22:16 ` hjl dot tools at gmail dot com
` (11 subsequent siblings)
13 siblings, 0 replies; 17+ messages in thread
From: hjl dot tools at gmail dot com @ 2009-12-26 22:13 UTC (permalink / raw)
To: gcc-bugs
------- Comment #2 from hjl dot tools at gmail dot com 2009-12-26 22:13 -------
It may be caused by revision 147716:
http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00693.html
--
hjl dot tools at gmail dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ebotcazou at gcc dot gnu dot
| |org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42512
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug middle-end/42512] [4.5 Regression] integer wrong code bug with loop
2009-12-26 19:27 [Bug c/42512] New: possible integer wrong code bug regehr at cs dot utah dot edu
2009-12-26 20:00 ` [Bug middle-end/42512] [4.5 Regression] integer wrong code bug with loop jakub at gcc dot gnu dot org
2009-12-26 22:13 ` hjl dot tools at gmail dot com
@ 2009-12-26 22:16 ` hjl dot tools at gmail dot com
2009-12-27 14:43 ` ebotcazou at gcc dot gnu dot org
` (10 subsequent siblings)
13 siblings, 0 replies; 17+ messages in thread
From: hjl dot tools at gmail dot com @ 2009-12-26 22:16 UTC (permalink / raw)
To: gcc-bugs
------- Comment #3 from hjl dot tools at gmail dot com 2009-12-26 22:16 -------
It is related to PR 41497.
--
hjl dot tools at gmail dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |spop at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42512
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug middle-end/42512] [4.5 Regression] integer wrong code bug with loop
2009-12-26 19:27 [Bug c/42512] New: possible integer wrong code bug regehr at cs dot utah dot edu
` (2 preceding siblings ...)
2009-12-26 22:16 ` hjl dot tools at gmail dot com
@ 2009-12-27 14:43 ` ebotcazou at gcc dot gnu dot org
2010-01-08 14:07 ` rguenth at gcc dot gnu dot org
` (9 subsequent siblings)
13 siblings, 0 replies; 17+ messages in thread
From: ebotcazou at gcc dot gnu dot org @ 2009-12-27 14:43 UTC (permalink / raw)
To: gcc-bugs
------- Comment #4 from ebotcazou at gcc dot gnu dot org 2009-12-27 14:43 -------
> It may be caused by revision 147716:
>
> http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00693.html
Same trigger as the other so the same partial reversion works:
Index: tree-scalar-evolution.c
===================================================================
--- tree-scalar-evolution.c (revision 155361)
+++ tree-scalar-evolution.c (working copy)
@@ -1159,7 +1159,7 @@ follow_ssa_edge_expr (struct loop *loop,
switch (code)
{
- CASE_CONVERT:
+ case NOP_EXPR:
/* This assignment is under the form "a_1 = (cast) rhs. */
res = follow_ssa_edge_expr (loop, at_stmt, TREE_OPERAND (expr, 0),
halting_phi, evolution_of_loop, limit);
@@ -1222,7 +1222,7 @@ follow_ssa_edge_in_rhs (struct loop *loo
switch (code)
{
- CASE_CONVERT:
+ case NOP_EXPR:
/* This assignment is under the form "a_1 = (cast) rhs. */
res = follow_ssa_edge_expr (loop, stmt, gimple_assign_rhs1 (stmt),
halting_phi, evolution_of_loop, limit);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42512
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug middle-end/42512] [4.5 Regression] integer wrong code bug with loop
2009-12-26 19:27 [Bug c/42512] New: possible integer wrong code bug regehr at cs dot utah dot edu
` (3 preceding siblings ...)
2009-12-27 14:43 ` ebotcazou at gcc dot gnu dot org
@ 2010-01-08 14:07 ` rguenth at gcc dot gnu dot org
2010-01-08 15:00 ` rguenth at gcc dot gnu dot org
` (8 subsequent siblings)
13 siblings, 0 replies; 17+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2010-01-08 14:07 UTC (permalink / raw)
To: gcc-bugs
------- Comment #5 from rguenth at gcc dot gnu dot org 2010-01-08 14:07 -------
I believe we can only either allow truncations or widenings in following
SSA edges. Otherwise we miss that in
int l_2;
for (l_2 = -1; l_2 != 0; l_2 = (unsigned char)(l_2 - 1))
g_3 |= l_2;
the evolution is irregular in that the initial value is integer -1. That is
what happens - we compute the evolution of the result of (unsigned char)(l_2
-1)
as { 255, +, 255 }_1 but we may not use this evolution to derive that of
the value assigned to l_2, (int) { 255, +, 255 }_1 because we cannot represent
this. The correct evolution is -1, 254, 253 ..., 0 which isn't representable.
Thus I think we need to either kill the conversion code completely or
at least severely restrict it with sth like
Index: gcc/tree-scalar-evolution.c
===================================================================
--- gcc/tree-scalar-evolution.c (revision 155732)
+++ gcc/tree-scalar-evolution.c (working copy)
@@ -1161,9 +1161,19 @@ follow_ssa_edge_expr (struct loop *loop,
{
CASE_CONVERT:
/* This assignment is under the form "a_1 = (cast) rhs. */
- res = follow_ssa_edge_expr (loop, at_stmt, TREE_OPERAND (expr, 0),
- halting_phi, evolution_of_loop, limit);
- *evolution_of_loop = chrec_convert (type, *evolution_of_loop, at_stmt);
+ rhs0 = TREE_OPERAND (expr, 0);
+ if (TYPE_PRECISION (type) == TYPE_PRECISION (TREE_TYPE (rhs0))
+ || TREE_CODE (*evolution_of_loop) != POLYNOMIAL_CHREC)
+ {
+ res = follow_ssa_edge_expr (loop, at_stmt, TREE_OPERAND (expr, 0),
+ halting_phi, evolution_of_loop, limit);
+ *evolution_of_loop = chrec_convert (type, *evolution_of_loop,
at_stmt);
+ }
+ else
+ {
+ *evolution_of_loop = chrec_dont_know;
+ res = t_false;
+ }
break;
case INTEGER_CST:
@@ -1219,14 +1229,25 @@ follow_ssa_edge_in_rhs (struct loop *loo
enum tree_code code = gimple_assign_rhs_code (stmt);
tree type = gimple_expr_type (stmt), rhs1, rhs2;
t_bool res;
+ tree name;
switch (code)
{
CASE_CONVERT:
/* This assignment is under the form "a_1 = (cast) rhs. */
- res = follow_ssa_edge_expr (loop, stmt, gimple_assign_rhs1 (stmt),
- halting_phi, evolution_of_loop, limit);
- *evolution_of_loop = chrec_convert (type, *evolution_of_loop, stmt);
+ name = gimple_assign_rhs1 (stmt);
+ if (TYPE_PRECISION (type) == TYPE_PRECISION (TREE_TYPE (name))
+ || TREE_CODE (*evolution_of_loop) != POLYNOMIAL_CHREC)
+ {
+ res = follow_ssa_edge_expr (loop, stmt, gimple_assign_rhs1 (stmt),
+ halting_phi, evolution_of_loop, limit);
+ *evolution_of_loop = chrec_convert (type, *evolution_of_loop, stmt);
+ }
+ else
+ {
+ *evolution_of_loop = chrec_dont_know;
+ res = t_false;
+ }
break;
case POINTER_PLUS_EXPR:
@@ -1759,7 +1780,11 @@ interpret_rhs_expr (struct loop *loop, g
CASE_CONVERT:
chrec1 = analyze_scalar_evolution (loop, rhs1);
- res = chrec_convert (type, chrec1, at_stmt);
+ if (TYPE_PRECISION (type) == TYPE_PRECISION (TREE_TYPE (rhs1))
+ || TREE_CODE (chrec1) != POLYNOMIAL_CHREC)
+ res = chrec_convert (type, chrec1, at_stmt);
+ else
+ res = chrec_dont_know;
break;
default:
Sebastian - any better idea? This will at least regress
FAIL: gcc.dg/tree-ssa/scev-cast.c scan-tree-dump-times optimized "= \(unsigned
char\)" 1
FAIL: gcc.dg/tree-ssa/scev-cast.c scan-tree-dump-times optimized "= \(char\)" 1
because we cannot distinguish the really critical cases from ok ones.
The patch in comment #4 just makes the issue latent again.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42512
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug middle-end/42512] [4.5 Regression] integer wrong code bug with loop
2009-12-26 19:27 [Bug c/42512] New: possible integer wrong code bug regehr at cs dot utah dot edu
` (4 preceding siblings ...)
2010-01-08 14:07 ` rguenth at gcc dot gnu dot org
@ 2010-01-08 15:00 ` rguenth at gcc dot gnu dot org
2010-01-08 16:20 ` spop at gcc dot gnu dot org
` (7 subsequent siblings)
13 siblings, 0 replies; 17+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2010-01-08 15:00 UTC (permalink / raw)
To: gcc-bugs
------- Comment #6 from rguenth at gcc dot gnu dot org 2010-01-08 15:00 -------
Hm, actually what is wrong is the evolution of l_2_18:
(scalar = l_2_18)
(scalar_evolution = {255, +, 0x0ffffffff}_1))
that of l_2_10 is correct:
(scalar = l_2_10)
(scalar_evolution = (unsigned int) {254, +, 255}_1))
<bb 3>:
# l_2_18 = PHI <l_2_10(4), 0x0ffffffff(2)>
# prephitmp.10_25 = PHI <g_3.2_7(4), pretmp.9_24(2)>
# ivtmp.19_37 = PHI <ivtmp.19_29(4), 255(2)>
D.1960_3 = (short unsigned int) l_2_18;
g_3.1_5 = (short unsigned int) prephitmp.10_25;
D.1963_6 = D.1960_3 | g_3.1_5;
g_3.2_7 = (short int) D.1963_6;
g_3_lsm.18_11 = g_3.2_7;
D.1965_8 = (unsigned char) l_2_18;
D.1966_9 = D.1965_8 + 255;
l_2_10 = (unsigned int) D.1966_9;
ivtmp.19_29 = ivtmp.19_37 - 1;
if (ivtmp.19_29 != 0)
goto <bb 4>;
else
goto <bb 5>;
<bb 4>:
goto <bb 3>;
Thus we need to verify we maintain the correct initial condition only?
Like for example with
Index: tree-scalar-evolution.c
===================================================================
--- tree-scalar-evolution.c (revision 155732)
+++ tree-scalar-evolution.c (working copy)
@@ -1642,6 +1642,15 @@ interpret_loop_phi (struct loop *loop, g
init_cond = analyze_initial_condition (loop_phi_node);
res = analyze_evolution_in_loop (loop_phi_node, init_cond);
+ /* Verify we maintained the correct initial condition throughout
+ possible conversions in the SSA chain. */
+ if (res != chrec_dont_know)
+ {
+ tree new_init = initial_condition (res);
+ if (!operand_equal_p (init_cond, new_init, 0))
+ return chrec_dont_know;
+ }
+
return res;
}
Maybe too strict in case the returned chrec is wrapped in a conversion
operation itself (no idea if that ever happens - at least initial_condition
doesn't seem to deal with that during recursion either).
I'm going to test that patch.
--
rguenth at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot
|dot org |org
Status|NEW |ASSIGNED
Last reconfirmed|2009-12-26 20:00:19 |2010-01-08 15:00:44
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42512
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug middle-end/42512] [4.5 Regression] integer wrong code bug with loop
2009-12-26 19:27 [Bug c/42512] New: possible integer wrong code bug regehr at cs dot utah dot edu
` (5 preceding siblings ...)
2010-01-08 15:00 ` rguenth at gcc dot gnu dot org
@ 2010-01-08 16:20 ` spop at gcc dot gnu dot org
2010-01-08 16:53 ` rguenth at gcc dot gnu dot org
` (6 subsequent siblings)
13 siblings, 0 replies; 17+ messages in thread
From: spop at gcc dot gnu dot org @ 2010-01-08 16:20 UTC (permalink / raw)
To: gcc-bugs
------- Comment #7 from spop at gcc dot gnu dot org 2010-01-08 16:20 -------
Subject: Re: [4.5 Regression] integer wrong code bug
with loop
I like the patch that you proposed in Comment #6.
Let's see if it passes bootstrap and test.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42512
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug middle-end/42512] [4.5 Regression] integer wrong code bug with loop
2009-12-26 19:27 [Bug c/42512] New: possible integer wrong code bug regehr at cs dot utah dot edu
` (6 preceding siblings ...)
2010-01-08 16:20 ` spop at gcc dot gnu dot org
@ 2010-01-08 16:53 ` rguenth at gcc dot gnu dot org
2010-01-08 17:07 ` rguenth at gcc dot gnu dot org
` (5 subsequent siblings)
13 siblings, 0 replies; 17+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2010-01-08 16:53 UTC (permalink / raw)
To: gcc-bugs
------- Comment #8 from rguenth at gcc dot gnu dot org 2010-01-08 16:53 -------
It FAILs
FAIL: gcc.dg/vect/pr36630.c scan-tree-dump-times vect "vectorized 1 loops" 1
but otherwise passes testing. I'll see what effect it has on SPEC 2006 and
investigate the above.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42512
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug middle-end/42512] [4.5 Regression] integer wrong code bug with loop
2009-12-26 19:27 [Bug c/42512] New: possible integer wrong code bug regehr at cs dot utah dot edu
` (7 preceding siblings ...)
2010-01-08 16:53 ` rguenth at gcc dot gnu dot org
@ 2010-01-08 17:07 ` rguenth at gcc dot gnu dot org
2010-01-08 17:21 ` rguenth at gcc dot gnu dot org
` (4 subsequent siblings)
13 siblings, 0 replies; 17+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2010-01-08 17:07 UTC (permalink / raw)
To: gcc-bugs
------- Comment #9 from rguenth at gcc dot gnu dot org 2010-01-08 17:07 -------
Ok, exactly the case I thought of (a conversion around the CHREC). I'll see to
fix that up.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42512
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug middle-end/42512] [4.5 Regression] integer wrong code bug with loop
2009-12-26 19:27 [Bug c/42512] New: possible integer wrong code bug regehr at cs dot utah dot edu
` (8 preceding siblings ...)
2010-01-08 17:07 ` rguenth at gcc dot gnu dot org
@ 2010-01-08 17:21 ` rguenth at gcc dot gnu dot org
2010-01-08 17:55 ` Sebastian Pop
2010-01-08 17:55 ` sebpop at gmail dot com
` (3 subsequent siblings)
13 siblings, 1 reply; 17+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2010-01-08 17:21 UTC (permalink / raw)
To: gcc-bugs
------- Comment #10 from rguenth at gcc dot gnu dot org 2010-01-08 17:21 -------
Ok, I have that fixed locally at the place of the patch but I wonder if
initial_condition () shouldn't return for example
1ul for (unsigned long) { 1, +, 1 }_1
and
(int) i_2 for (int) { i_2, +, 1 }_1
and further (for short i_2)
i_2 for (short) { (int) { i_2, +, 1 }_2, +, 1 }_1
? Can the latter two happen all? Is it even correct to talk about a
general initial condition in this case? Consider
{ { 1, +, 1 }_2, +, 1 }_1
initial_condition will return 1 for the chrec even though that is not
correct because the initial condition is not constant in loop 1.
I suppose I'd only see that if instantiating the chrec at the point
where I placed the fix? So I really only see at most a single outer
conversion around the chrec?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42512
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Bug middle-end/42512] [4.5 Regression] integer wrong code bug with loop
2010-01-08 17:21 ` rguenth at gcc dot gnu dot org
@ 2010-01-08 17:55 ` Sebastian Pop
0 siblings, 0 replies; 17+ messages in thread
From: Sebastian Pop @ 2010-01-08 17:55 UTC (permalink / raw)
To: gcc-bugzilla; +Cc: gcc-bugs
> Ok, I have that fixed locally at the place of the patch but I wonder if
> initial_condition () shouldn't return for example
>
> 1ul for (unsigned long) { 1, +, 1 }_1
>
This is correct.
> and
>
> (int) i_2 for (int) { i_2, +, 1 }_1
>
> and further (for short i_2)
>
> i_2 for (short) { (int) { i_2, +, 1 }_2, +, 1 }_1
>
> ? Can the latter two happen all?
Yes, these could happen, and you are right, we should see
the initial value of a chrec through the type conversion lenses.
> Is it even correct to talk about a
> general initial condition in this case? Consider
>
> { { 1, +, 1 }_2, +, 1 }_1
>
> initial_condition will return 1 for the chrec even though that is not
> correct because the initial condition is not constant in loop 1.
If you want, there is an initial condition for the loop_1 and that would be
{1, +, 1}_2, and there is an initial condition 1 for loop nest loop_2:
loop_2
i = loop_2_phi (0, i+1) = {1, +, 1}_2
loop_1
j = loop_1_phi (i, j+1) = {{1, +, 1}_2, +, 1}_1
> I suppose I'd only see that if instantiating the chrec at the point
> where I placed the fix? So I really only see at most a single outer
> conversion around the chrec?
Yes, I think that at most you can have only one conversion around a chrec.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug middle-end/42512] [4.5 Regression] integer wrong code bug with loop
2009-12-26 19:27 [Bug c/42512] New: possible integer wrong code bug regehr at cs dot utah dot edu
` (9 preceding siblings ...)
2010-01-08 17:21 ` rguenth at gcc dot gnu dot org
@ 2010-01-08 17:55 ` sebpop at gmail dot com
2010-01-09 12:04 ` rguenth at gcc dot gnu dot org
` (2 subsequent siblings)
13 siblings, 0 replies; 17+ messages in thread
From: sebpop at gmail dot com @ 2010-01-08 17:55 UTC (permalink / raw)
To: gcc-bugs
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1485 bytes --]
------- Comment #11 from sebpop at gmail dot com 2010-01-08 17:55 -------
Subject: Re: [4.5 Regression] integer wrong code bug
with loop
> Ok, I have that fixed locally at the place of the patch but I wonder if
> initial_condition () shouldn't return for example
>
> Â 1ul for (unsigned long) { 1, +, 1 }_1
>
This is correct.
> and
>
> Â (int) i_2 for (int) { i_2, +, 1 }_1
>
> and further (for short i_2)
>
> Â i_2 for (short) { (int) { i_2, +, 1 }_2, +, 1 }_1
>
> ? Â Can the latter two happen all?
Yes, these could happen, and you are right, we should see
the initial value of a chrec through the type conversion lenses.
> Is it even correct to talk about a
> general initial condition in this case? Â Consider
>
> Â { { 1, +, 1 }_2, +, 1 }_1
>
> initial_condition will return 1 for the chrec even though that is not
> correct because the initial condition is not constant in loop 1.
If you want, there is an initial condition for the loop_1 and that would be
{1, +, 1}_2, and there is an initial condition 1 for loop nest loop_2:
loop_2
i = loop_2_phi (0, i+1) = {1, +, 1}_2
loop_1
j = loop_1_phi (i, j+1) = {{1, +, 1}_2, +, 1}_1
> I suppose I'd only see that if instantiating the chrec at the point
> where I placed the fix? Â So I really only see at most a single outer
> conversion around the chrec?
Yes, I think that at most you can have only one conversion around a chrec.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42512
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug middle-end/42512] [4.5 Regression] integer wrong code bug with loop
2009-12-26 19:27 [Bug c/42512] New: possible integer wrong code bug regehr at cs dot utah dot edu
` (10 preceding siblings ...)
2010-01-08 17:55 ` sebpop at gmail dot com
@ 2010-01-09 12:04 ` rguenth at gcc dot gnu dot org
2010-01-09 12:04 ` rguenth at gcc dot gnu dot org
2010-02-07 4:49 ` hjl at gcc dot gnu dot org
13 siblings, 0 replies; 17+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2010-01-09 12:04 UTC (permalink / raw)
To: gcc-bugs
------- Comment #13 from rguenth at gcc dot gnu dot org 2010-01-09 12:04 -------
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42512
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug middle-end/42512] [4.5 Regression] integer wrong code bug with loop
2009-12-26 19:27 [Bug c/42512] New: possible integer wrong code bug regehr at cs dot utah dot edu
` (11 preceding siblings ...)
2010-01-09 12:04 ` rguenth at gcc dot gnu dot org
@ 2010-01-09 12:04 ` rguenth at gcc dot gnu dot org
2010-02-07 4:49 ` hjl at gcc dot gnu dot org
13 siblings, 0 replies; 17+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2010-01-09 12:04 UTC (permalink / raw)
To: gcc-bugs
------- Comment #12 from rguenth at gcc dot gnu dot org 2010-01-09 12:04 -------
Subject: Bug 42512
Author: rguenth
Date: Sat Jan 9 12:04:17 2010
New Revision: 155757
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155757
Log:
2010-01-09 Richard Guenther <rguenther@suse.de>
PR middle-end/42512
* tree-scalar-evolution.c (interpret_loop_phi): Make sure
the evolution is compatible with the initial condition.
* gcc.c-torture/execute/pr42512.c: New testcase.
Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr42512.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-scalar-evolution.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42512
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug middle-end/42512] [4.5 Regression] integer wrong code bug with loop
2009-12-26 19:27 [Bug c/42512] New: possible integer wrong code bug regehr at cs dot utah dot edu
` (12 preceding siblings ...)
2010-01-09 12:04 ` rguenth at gcc dot gnu dot org
@ 2010-02-07 4:49 ` hjl at gcc dot gnu dot org
13 siblings, 0 replies; 17+ messages in thread
From: hjl at gcc dot gnu dot org @ 2010-02-07 4:49 UTC (permalink / raw)
To: gcc-bugs
------- Comment #14 from hjl at gcc dot gnu dot org 2010-02-07 04:45 -------
Subject: Bug 42512
Author: hjl
Date: Sun Feb 7 04:41:22 2010
New Revision: 156562
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156562
Log:
Backport testcases from mainline to 4.4.
2010-02-06 H.J. Lu <hongjiu.lu@intel.com>
Backport from mainline:
2010-02-05 Dodji Seketeli <dodji@redhat.com>
PR c++/42915
* g++.dg/other/crash-9.C: New test.
2010-02-03 Jason Merrill <jason@redhat.com>
PR c++/40138
* g++.dg/ext/builtin11.C: New.
2010-02-03 Richard Guenther <rguenther@suse.de>
PR tree-optimization/42944
* gcc.dg/errno-1.c: New testcase.
2010-02-03 Richard Guenther <rguenther@suse.de>
PR middle-end/42927
* gcc.c-torture/compile/pr42927.c: New testcase.
2010-01-29 Dodji Seketeli <dodji@redhat.com>
PR c++/42758
PR c++/42634
PR c++/42336
PR c++/42797
PR c++/42880
* g++.dg/other/crash-5.C: New test.
* g++.dg/other/crash-7.C: New test.
* g++.dg/other/crash-8.C: New test.
2010-01-28 Uros Bizjak <ubizjak@gmail.com>
PR target/42891
* gcc.target/i386/pr42891.c: New test.
2010-01-28 Richard Guenther <rguenther@suse.de>
PR middle-end/42883
* g++.dg/torture/pr42883.C: New testcase.
2010-01-28 Michael Matz <matz@suse.de>
* gcc.target/i386/pr42881.c: New test.
2010-01-28 Dodji Seketeli <dodji@redhat.com>
PR c++/42713
PR c++/42820
* g++.dg/template/typedef27.C: New test case.
* g++.dg/template/typedef28.C: New test case.
2010-01-27 Jakub Jelinek <jakub@redhat.com>
PR middle-end/42874
* gcc.dg/vla-22.c: New test.
2010-01-26 Richard Guenther <rguenther@suse.de>
PR tree-optimization/42250
* gcc.dg/pr42250.c: New testcase.
2010-01-25 Tobias Burnus <burnus@net-b.de>
PR fortran/42858
* gfortran.dg/generic_21.f90: New test.
2010-01-21 Martin Jambor <mjambor@suse.cz>
PR tree-optimization/42585
* gcc.dg/tree-ssa/pr42585.c: New test.
2010-01-20 Alexandre Oliva <aoliva@redhat.com>
PR debug/42715
* gcc.dg/pr42715.c: New.
2010-01-20 Richard Guenther <rguenther@suse.de>
PR tree-optimization/42717
* gcc.c-torture/compile/pr42717.c: New testcase.
2010-01-19 Paul Thomas <pault@gcc.gnu.org>
PR fortran/42783
* gfortran.dg/bounds_check_15.f90 : New test.
2010-01-18 Dodji Seketeli <dodji@redhat.com>
PR c++/42766
* g++.dg/conversion/op6.C: New test.
2010-01-18 Richard Guenther <rguenther@suse.de>
PR tree-optimization/42781
* gfortran.fortran-torture/compile/pr42781.f90: New testcase.
2010-01-17 Richard Guenther <rguenther@suse.de>
PR middle-end/42248
* gcc.c-torture/execute/pr42248.c: New testcase.
2010-01-17 Janus Weil <janus@gcc.gnu.org>
PR fortran/42677
* gfortran.dg/interface_assignment_5.f90: New test.
2010-01-15 Richard Guenther <rguenther@suse.de>
PR middle-end/42739
* g++.dg/torture/pr42739.C: New testcase.
2010-01-14 Jerry DeLisle <jvdelisle@gcc.gnu.org>
PR fortran/42684
* gfortran.dg/interface_31.f90: New test.
2010-01-14 Martin Jambor <mjambor@suse.cz>
PR tree-optimization/42706
* gcc.dg/ipa/pr42706.c: New testcase.
2010-01-14 Martin Jambor <mjambor@suse.cz>
PR tree-optimization/42714
* g++.dg/torture/pr42714.C: New test.
2010-01-14 Alexander Monakov <amonakov@ispras.ru>
PR rtl-optimization/42388
* gcc.dg/pr42388.c: New.
2010-01-14 Alexander Monakov <amonakov@ispras.ru>
PR rtl-optimization/42294
* gfortran.dg/pr42294.f: New.
2010-01-14 Ira Rosen <irar@il.ibm.com>
PR tree-optimization/42709
* gcc.dg/vect/pr42709.c: New test.
2010-01-13 Richard Guenther <rguenther@suse.de>
PR tree-optimization/42730
* gcc.c-torture/compile/pr42730.c: New testcase.
2010-01-13 Martin Jambor <mjambor@suse.cz>
PR tree-optimization/42704
* g++.dg/torture/pr42704.C: New test.
2010-01-13 Martin Jambor <mjambor@suse.cz>
PR tree-optimization/42703
* gcc.c-torture/compile/pr42703.c: New test.
2010-01-13 Richard Guenther <rguenther@suse.de>
PR tree-optimization/42705
* gcc.c-torture/compile/pr42705.c: New testcase.
2010-01-13 Richard Guenther <rguenther@suse.de>
PR middle-end/42716
* gcc.c-torture/compile/pr42716.c: New testcase.
2010-01-12 Joseph Myers <joseph@codesourcery.com>
PR c/42708
* gcc.c-torture/compile/pr42708-1.c: New test.
2010-01-09 Alexandre Oliva <aoliva@redhat.com>
PR middle-end/42363
* gcc.dg/torture/pr42363.c: New.
2010-01-09 Alexandre Oliva <aoliva@redhat.com>
PR debug/42604
PR debug/42395
* gcc.dg/vect/pr42604.c: New.
* gcc.dg/vect/pr42395.c: New.
2010-01-09 Richard Guenther <rguenther@suse.de>
PR middle-end/42512
* gcc.c-torture/execute/pr42512.c: New testcase.
Added:
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/conversion/op6.C
- copied unchanged from r156561,
trunk/gcc/testsuite/g++.dg/conversion/op6.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/ext/builtin11.C
- copied unchanged from r156561,
trunk/gcc/testsuite/g++.dg/ext/builtin11.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/other/crash-5.C
- copied unchanged from r156561,
trunk/gcc/testsuite/g++.dg/other/crash-5.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/other/crash-7.C
- copied unchanged from r156561,
trunk/gcc/testsuite/g++.dg/other/crash-7.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/other/crash-8.C
- copied unchanged from r156561,
trunk/gcc/testsuite/g++.dg/other/crash-8.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/other/crash-9.C
- copied unchanged from r156561,
trunk/gcc/testsuite/g++.dg/other/crash-9.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/typedef27.C
- copied unchanged from r156561,
trunk/gcc/testsuite/g++.dg/template/typedef27.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/typedef28.C
- copied unchanged from r156561,
trunk/gcc/testsuite/g++.dg/template/typedef28.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/torture/pr42704.C
- copied unchanged from r156561,
trunk/gcc/testsuite/g++.dg/torture/pr42704.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/torture/pr42714.C
- copied unchanged from r156561,
trunk/gcc/testsuite/g++.dg/torture/pr42714.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/torture/pr42739.C
- copied unchanged from r156561,
trunk/gcc/testsuite/g++.dg/torture/pr42739.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/torture/pr42883.C
- copied unchanged from r156561,
trunk/gcc/testsuite/g++.dg/torture/pr42883.C
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr42703.c
- copied unchanged from r156561,
trunk/gcc/testsuite/gcc.c-torture/compile/pr42703.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr42705.c
- copied unchanged from r156561,
trunk/gcc/testsuite/gcc.c-torture/compile/pr42705.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr42708-1.c
- copied unchanged from r156561,
trunk/gcc/testsuite/gcc.c-torture/compile/pr42708-1.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr42716.c
- copied unchanged from r156561,
trunk/gcc/testsuite/gcc.c-torture/compile/pr42716.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr42717.c
- copied unchanged from r156561,
trunk/gcc/testsuite/gcc.c-torture/compile/pr42717.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr42730.c
- copied unchanged from r156561,
trunk/gcc/testsuite/gcc.c-torture/compile/pr42730.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr42927.c
- copied unchanged from r156561,
trunk/gcc/testsuite/gcc.c-torture/compile/pr42927.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr42248.c
- copied unchanged from r156561,
trunk/gcc/testsuite/gcc.c-torture/execute/pr42248.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr42512.c
- copied unchanged from r156561,
trunk/gcc/testsuite/gcc.c-torture/execute/pr42512.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/errno-1.c
- copied unchanged from r156561, trunk/gcc/testsuite/gcc.dg/errno-1.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/ipa/pr42706.c
- copied unchanged from r156561, trunk/gcc/testsuite/gcc.dg/ipa/pr42706.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr42250.c
- copied unchanged from r156561, trunk/gcc/testsuite/gcc.dg/pr42250.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr42388.c
- copied unchanged from r156561, trunk/gcc/testsuite/gcc.dg/pr42388.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr42715.c
- copied unchanged from r156561, trunk/gcc/testsuite/gcc.dg/pr42715.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/torture/pr42363.c
- copied unchanged from r156561,
trunk/gcc/testsuite/gcc.dg/torture/pr42363.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/tree-ssa/pr42585.c
- copied unchanged from r156561,
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr42585.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/vect/pr42395.c
- copied unchanged from r156561,
trunk/gcc/testsuite/gcc.dg/vect/pr42395.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/vect/pr42604.c
- copied unchanged from r156561,
trunk/gcc/testsuite/gcc.dg/vect/pr42604.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/vect/pr42709.c
- copied unchanged from r156561,
trunk/gcc/testsuite/gcc.dg/vect/pr42709.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/vla-22.c
- copied unchanged from r156561, trunk/gcc/testsuite/gcc.dg/vla-22.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.target/i386/pr42881.c
- copied unchanged from r156561,
trunk/gcc/testsuite/gcc.target/i386/pr42881.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.target/i386/pr42891.c
- copied unchanged from r156561,
trunk/gcc/testsuite/gcc.target/i386/pr42891.c
branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/bounds_check_15.f90
- copied unchanged from r156561,
trunk/gcc/testsuite/gfortran.dg/bounds_check_15.f90
branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/generic_21.f90
- copied unchanged from r156561,
trunk/gcc/testsuite/gfortran.dg/generic_21.f90
branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/interface_31.f90
- copied unchanged from r156561,
trunk/gcc/testsuite/gfortran.dg/interface_31.f90
branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/interface_assignment_5.f90
- copied unchanged from r156561,
trunk/gcc/testsuite/gfortran.dg/interface_assignment_5.f90
branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/pr42294.f
- copied unchanged from r156561,
trunk/gcc/testsuite/gfortran.dg/pr42294.f
branches/gcc-4_4-branch/gcc/testsuite/gfortran.fortran-torture/compile/pr42781.f90
- copied unchanged from r156561,
trunk/gcc/testsuite/gfortran.fortran-torture/compile/pr42781.f90
Modified:
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42512
^ permalink raw reply [flat|nested] 17+ messages in thread