[Bug tree-optimization/22026] [4.1 Regression] ACATS FAIL C45331A fixed point wrong code (VRP related)
--- Additional Comments From kazu at cs dot umass dot edu 2005-06-26 03:51 --- Just checked in a patch. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22026
[Bug tree-optimization/22117] [4.1 Regression] VRP thinks + is always nonnull.
--- Additional Comments From kazu at cs dot umass dot edu 2005-06-24 01:59 --- Just checked in a patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22117
[Bug middle-end/22156] [4.0/4.1 Regression] bit-field copying regressed
-- What|Removed |Added CC||kazu at cs dot umass dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22156
[Bug tree-optimization/22117] [4.1 Regression] VRP thinks + is always nonnull.
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |kazu at cs dot umass dot edu |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22117
[Bug tree-optimization/22117] New: VRP thinks + is always nonnull.
Consider:
void
foo (int *p, int q)
{
if (p == 0)
{
if (q == 0)
{
int *r = &p[q];
if (r != 0)
link_error ();
}
}
}
Note that the innermost "if" condition should be folded to false,
but VRP folds that to true.
Under "if (q == 0)", both p and q are known to be zero,
but VRP thinks that regardless of their values, p + q is always nonnull.
--
Summary: VRP thinks + is always nonnull.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kazu at cs dot umass dot edu
CC: dnovillo at redhat dot com,gcc-bugs at gcc dot gnu dot
org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22117
[Bug tree-optimization/22026] [4.1 Regression] ACATS FAIL C45331A fixed point wrong code (VRP related)
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |kazu at cs dot umass dot edu |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22026
[Bug tree-optimization/21849] wrong use of sbitmap in tree-ssa-copy.c
--- Additional Comments From kazu at cs dot umass dot edu 2005-06-03 04:09 --- Just checked in a patch. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21849
[Bug tree-optimization/21849] wrong use of sbitmap in tree-ssa-copy.c
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |kazu at cs dot umass dot edu |dot org | Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21849
[Bug tree-optimization/21849] New: wrong use of sbitmap in tree-ssa-copy.c
visited = sbitmap_alloc (num_ssa_names); does not come with a call to sbitmap_clear. -- Summary: wrong use of sbitmap in tree-ssa-copy.c Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P2 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kazu at cs dot umass dot edu CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21849
[Bug tree-optimization/21791] New: ccp and copy-prop print out too much garbage with -fdump-tree-ccp/copy-details
CCP and COPY-PROP print out garbage like Replaced x_6 = 1; with x_6 = 1; Replaced :; with :; The dump would look a lot nicer if they print out statements that have been changed. -- Summary: ccp and copy-prop print out too much garbage with - fdump-tree-ccp/copy-details Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kazu at cs dot umass dot edu CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21791
[Bug tree-optimization/21658] CCP does not propagate ADDR_EXPR far enough.
--- Additional Comments From kazu at cs dot umass dot edu 2005-05-27 16:33 --- Just checked in a patch. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21658
[Bug tree-optimization/21765] New: -free-vrp is undocumented.
-- Summary: -free-vrp is undocumented. Product: gcc Version: unknown Status: UNCONFIRMED Keywords: documentation Severity: normal Priority: P2 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kazu at cs dot umass dot edu CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21765
[Bug tree-optimization/21705] FRE does not eliminate a redundant pure call.
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dberlin at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21705
[Bug tree-optimization/21348] tree-vrp.c:has_assert_expr is useless.
-- What|Removed |Added BugsThisDependsOn||18373 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21348
[Bug tree-optimization/21076] [4.1 Regression] ACATs ICE cxh1001 at tree-vrp.c:124
-- What|Removed |Added BugsThisDependsOn||18373 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21076
[Bug tree-optimization/21582] (optimisation) VRP pass could/should use non-null function attribute
-- What|Removed |Added BugsThisDependsOn||18373 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21582
[Bug tree-optimization/21705] New: FRE does not catch eliminate a redundant pute call.
Consider:
extern unsigned int strlen (const char *) __attribute__ ((__pure__));
void
foo (const char *str)
{
unsigned int a = strlen (str);
unsigned int b = strlen (str);
if (a != b)
link_error ();
}
FRE does not eliminate the second call to strlen.
--
Summary: FRE does not catch eliminate a redundant pute call.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kazu at cs dot umass dot edu
CC: dberlin at gcc dot gnu dot org,gcc-bugs at gcc dot gnu
dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21705
[Bug tree-optimization/21694] Missed forwprop opportunity into COND_EXPR
--- Additional Comments From kazu at cs dot umass dot edu 2005-05-21 17:01 --- (In reply to comment #2) > There is a reason why forwprop does not do this, the SSA_NAME is used twice. If we run forwprop > before FRE, it will catch it in this We are interested in the number of immediate uses of cond_4, not D.1240_3. Since cond_4 is used only once, this optimization fits in the framework of forwprop quite nicely. I've got a patch. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |kazu at cs dot umass dot edu |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21694
[Bug tree-optimization/21694] Missed forwprop opportunity into COND_EXPR
--- Additional Comments From kazu at cs dot umass dot edu 2005-05-21 09:45 --- The DOM's optimization comes from find_equivalent_equality_comparison, which makes a COND_EXPR absorb a narrowing cast. We could port this to tree-ssa-forwprop.c. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21694
[Bug tree-optimization/21694] New: Missed forwprop opportunity into COND_EXPR
Consider:
enum tree_code {
AAA,
BBB,
CCC
};
struct tree_common {
enum tree_code code : 8;
};
int
foo (struct tree_common *p)
{
enum tree_code code = p->code;
if (code == 0)
return p->code;
return 123;
}
After forwprop, the code leading up to the COND_EXPR looks like so:
D.1240_3 = p_2->code;
code_4 = (tree_code) D.1240_3;
if (code_4 == 0) goto ; else goto ;
After DOM, the code leading up to the COND_EXPR looks like so:
D.1240_3 = p_2->code;
code_4 = (tree_code) D.1240_3;
if (D.1240_3 == 0) goto ; else goto ;
Note that the COND_EXPR now uses D.1240_3.
--
Summary: Missed forwprop opportunity into COND_EXPR
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kazu at cs dot umass dot edu
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21694
[Bug tree-optimization/21658] CCP does not propagate ADDR_EXPR far enough.
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |kazu at cs dot umass dot edu |dot org | Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21658
[Bug tree-optimization/21658] New: CCP does not propagate ADDR_EXPR far enough.
Consider:
void
f (void)
{
int *p, *q, *r;
int a[10];
p = &a[5];
q = p - 1;
r = q - 1;
*r = 1;
}
Here is what I get from the first CCP.
f ()
{
int a[10];
int * r;
int * q;
int * p;
:
p_1 = &a[5];
q_2 = &a[4];
r_3 = q_2 - 4B;
*r_3 = 1;
return;
}
Note that p_1 and q_2 are of the form &a[CST], but r_3 is not.
--
Summary: CCP does not propagate ADDR_EXPR far enough.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kazu at cs dot umass dot edu
CC: dnovillo at redhat dot com,gcc-bugs at gcc dot gnu dot
org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21658
[Bug tree-optimization/21636] Missed ccp optimization
--- Additional Comments From kazu at cs dot umass dot edu 2005-05-18 20:56
---
Confirmed.
Here is what I get from the first CCP.
int g() ()
{
int * i;
struct f * a1;
struct f a;
int D.1687;
:
a.i = 1;
a1_3 = &a;
i_4 = &a.i;
D.1687_5 = *i_4;
D.1687_6 = D.1687_5;
return D.1687_6;
}
As Andrew has stated, the propagator does not know that i_4 == &a.i,
which is a gimple min invariant. This prevents *i_4 from being folded
to a.i.
The problem is that ccp_fold does not know how to fold &(&a)->i.
Teaching ccp_fold solves this problem.
Unfortunately, we cannot call fold_stmt because it destructively folds
a statement. We need a folder that returns a folded expression without
modifying the original expression.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00 |2005-05-18 20:56:07
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21636
[Bug tree-optimization/21636] Missed ccp optimization
-- What|Removed |Added CC||kazu at cs dot umass dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21636
[Bug tree-optimization/21576] FRE does not eliminate a redundant builtin call.
-- What|Removed |Added Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21576
[Bug tree-optimization/21576] New: FRE does not eliminate a redundant builtin call.
Consider:
int
foo (unsigned long a)
{
int b = __builtin_clzl (a);
int c = __builtin_clzl (a);
if (b == c)
return 1;
return 0;
}
Here is what I get after FRE.
foo (a)
{
int c;
int b;
int D.1235;
:
b_3 = __builtin_clzl (a_2);
c_4 = __builtin_clzl (a_2);
if (b_3 == c_4) goto ; else goto ;
:;
D.1235_7 = 1;
goto ();
:;
D.1235_6 = 0;
# D.1235_1 = PHI <1(1), 0(2)>;
:;
return D.1235_1;
}
DOM catches this later.
--
Summary: FRE does not eliminate a redundant builtin call.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kazu at cs dot umass dot edu
CC: dberlin at gcc dot gnu dot org,gcc-bugs at gcc dot gnu
dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21576
[Bug tree-optimization/21574] New: store_ccp doesn't see through a store.
Consider:
int
foo (int *p)
{
*p = 0;
return *p;
}
Here is what I get after store_ccp (with -fno-tree-dominator-opts)
foo (p)
{
int D.1233;
:
# TMT.0_5 = V_MAY_DEF ;
*p_1 = 0;
# VUSE ;
D.1233_2 = *p_1;
return D.1233_2;
}
Note that the return statement isn't changed to "return 0;".
--
Summary: store_ccp doesn't see through a store.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kazu at cs dot umass dot edu
CC: dnovillo at redhat dot com,gcc-bugs at gcc dot gnu dot
org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21574
[Bug tree-optimization/21563] A trivial VRP opportunity missed
--- Additional Comments From kazu at cs dot umass dot edu 2005-05-14 20:33 --- Just checked in a patch. -- What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||05/msg01346.html Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21563
[Bug tree-optimization/21289] A numeric range is spoiled by a symblic one in VRP
--- Additional Comments From kazu at cs dot umass dot edu 2005-05-14 19:40
---
Another case of a numeric value range spoiled by a symbolic one:
int
foo (int a, int b)
{
if (a == 0)
return 0;
if (a == b)
if (a == 0)
return 123;
return 456;
}
Reduced from c-common.c.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21289
[Bug tree-optimization/21563] A trivial VRP opportunity missed
--- Additional Comments From kazu at cs dot umass dot edu 2005-05-14 01:38 --- I've got a patch. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |kazu at cs dot umass dot edu |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21563
[Bug tree-optimization/21563] New: A trivial VRP opportunity missed
Consider:
int
foo (int a)
{
if (a > 1)
if (a == 0)
return 1;
return 0;
}
The second "if" statement is not folded.
--
Summary: A trivial VRP opportunity missed
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kazu at cs dot umass dot edu
CC: dnovillo at redhat dot com,gcc-bugs at gcc dot gnu dot
org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21563
[Bug tree-optimization/18472] TREE_OPERAND (t, 1) is referenced for t being GOTO_EXPR
--- Additional Comments From kazu at cs dot umass dot edu 2005-05-11 18:30 --- Just checked in a patch. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18472
[Bug tree-optimization/18472] TREE_OPERAND (t, 1) is referenced for t being GOTO_EXPR
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |kazu at cs dot umass dot edu |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||05/msg01018.html Status|NEW |ASSIGNED Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18472
[Bug tree-optimization/21367] VRP does not fold "if (a == b)" in a certain situation
--- Additional Comments From kazu at cs dot umass dot edu 2005-05-11 03:04 --- I've got a patch in testing. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |kazu at cs dot umass dot edu |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21367
[Bug tree-optimization/21170] [4.1 Regression] Comments still mention rewrite_ssa_into_ssa.
--- Additional Comments From kazu at cs dot umass dot edu 2005-05-10 20:22 --- Just checked in a patch. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21170
[Bug tree-optimization/21458] VRP does not remove a conditional in a loop
--- Additional Comments From kazu at cs dot umass dot edu 2005-05-10 05:47 --- DOM leaves PHI nodes like # i_5 = PHI <1(0)>; Then SCEV gives a symbolic initial value like i_5 with the step being 1. So the information from SCEV is useless here. With a tcb-like pass ordering (running VRP after CCP, COPY-PROP, etc but before DOM), we don't see a degenerate PHI node like above. Then it's just a matter of making vrp_meet slightly aggressive on meeting two VR_RANGEs. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |kazu at cs dot umass dot edu |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21458
[Bug tree-optimization/8681] Generates unneeded test
--- Additional Comments From kazu at cs dot umass dot edu 2005-05-10 05:37 --- The same patch for PR 21458 would work. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |kazu at cs dot umass dot edu |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8681
[Bug testsuite/21443] Most testcases with -fdump-tree-store_ccp aren't actually testing CCP itself.
--- Additional Comments From kazu at cs dot umass dot edu 2005-05-10 00:59 --- Just checked in a patch. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21443
[Bug tree-optimization/21458] New: VRP does not remove a conditional in a loop
Consider
extern void g (void);
extern void bar (int);
int
foo (int a)
{
int i;
for (i = 1; i < 100; i++)
{
if (i)
g ();
}
/* Force VRP to run. */
if (a)
bar (a);
}
VRP does not remove the first "if" statement.
--
Summary: VRP does not remove a conditional in a loop
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kazu at cs dot umass dot edu
CC: dnovillo at redhat dot com,gcc-bugs at gcc dot gnu dot
org,steven at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21458
[Bug tree-optimization/15838] "Inline" value of static struct
--- Additional Comments From kazu at cs dot umass dot edu 2005-05-08 21:30 --- Just checked in a patch. -- What|Removed |Added Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15838
[Bug tree-optimization/15838] "Inline" value of static struct
-- Bug 15838 depends on bug 14841, which changed state. Bug 14841 Summary: [tree-ssa] const_array[CST] is not folded http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14841 What|Old Value |New Value Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15838
[Bug tree-optimization/8826] "a >> b" differs from "a.operator>>(b)" in that virtual function calls are not avoided
-- Bug 8826 depends on bug 14841, which changed state. Bug 14841 Summary: [tree-ssa] const_array[CST] is not folded http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14841 What|Old Value |New Value Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8826
[Bug middle-end/14840] [tree-ssa] fold tree_code_type[CST] and tree_code_length[CST] in GCC itself
-- Bug 14840 depends on bug 14841, which changed state. Bug 14841 Summary: [tree-ssa] const_array[CST] is not folded http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14841 What|Old Value |New Value Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14840
[Bug tree-optimization/14841] [tree-ssa] const_array[CST] is not folded
--- Additional Comments From kazu at cs dot umass dot edu 2005-05-08 21:30 --- Just checked in a patch. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14841
[Bug c++/21454] New: const array doesn't live in the rodata section in C++
Consider:
static const int array[] = { 0, 1, 2, 3 };
int
foo (unsigned int i)
{
return array[i];
}
I get:
.file "test.cc"
.text
.align 2
.p2align 2,,3
.globl _Z3fooj
.type _Z3fooj, @function
_Z3fooj:
.LFB2:
movl4(%esp), %eax
movlarray(,%eax,4), %eax
ret
.LFE2:
.size _Z3fooj, .-_Z3fooj
.data
.align 4
.type array, @object
.size array, 16
array:
.long 0
.long 1
.long 2
.long 3
.ident "GCC: (GNU) 4.1.0 20050508 (experimental)"
.section.note.GNU-stack,"",@progbits
Note ".data". We could use ".rodata" for this array.
--
Summary: const array doesn't live in the rodata section in C++
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kazu at cs dot umass dot edu
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21454
[Bug testsuite/21443] ssa-ccp-9.c etc is broken
--- Additional Comments From kazu at cs dot umass dot edu 2005-05-07 17:02
---
A quick grep for fdump-tree-store_ccp shows
20030731-2.c:/* { dg-options "-O1 -fdump-tree-store_ccp" } */
20030917-1.c:/* { dg-options "-O1 -fdump-tree-store_ccp" } */
20030917-3.c:/* { dg-options "-O1 -fno-tree-dominator-opts
-fdump-tree-store_ccp" } */
20040721-1.c:/* { dg-options "-O2 -fdump-tree-store_ccp-vops" } */
ssa-ccp-1.c:/* { dg-options "-O1 -fdump-tree-store_ccp" } */
ssa-ccp-2.c:/* { dg-options "-O1 -fdump-tree-store_ccp" } */
ssa-ccp-3.c:/* { dg-options "-O1 -fdump-tree-store_ccp" } */
ssa-ccp-7.c:/* { dg-options "-O1 -fdump-tree-store_ccp" } */
ssa-ccp-9.c:/* { dg-options "-O1 -fdump-tree-store_ccp" } */
So store_ccp isn't enabled in most of these.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21443
[Bug testsuite/21443] ssa-ccp-9.c etc is broken
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |kazu at cs dot umass dot edu |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21443
[Bug tree-optimization/14705] [tree-ssa] more alias analysis needed!?
--- Additional Comments From kazu at cs dot umass dot edu 2005-05-07 15:03
---
FWIW, here is the last SSA form I get with vops.
foo (p)
{
int D.1241;
int global.0;
int D.1239;
:
# VUSE ;
D.1239_2 = p_1->c;
if (D.1239_2 != 0) goto ; else goto ;
:;
# VUSE ;
global.0_4 = global;
D.1241_5 = global.0_4 + 1;
# global_6 = V_MUST_DEF ;
global = D.1241_5;
# VUSE ;
D.1239_7 = p_1->c;
if (D.1239_7 == 0) goto ; else goto ;
:;
# global_8 = V_MAY_DEF ;
bar () [tail call];
:;
return;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14705
[Bug testsuite/21443] New: ssa-ccp-9.c etc is broken
It uses -O1 -fdump-tree-store_ccp and tests for lack of link_error, but note that store_ccp is enabled with -O2 or higher. So the testcase is testing something that happens in some other optimizer like DOM. -- Summary: ssa-ccp-9.c etc is broken Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P2 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kazu at cs dot umass dot edu CC: dnovillo at redhat dot com,gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21443
[Bug middle-end/14840] [tree-ssa] fold tree_code_type[CST] and tree_code_length[CST] in GCC itself
--- Additional Comments From kazu at cs dot umass dot edu 2005-05-07 05:14 --- In *.final_cleanup of cc1-i files with --enable-checking, I see 1308 occurrences of tree_code_type[CST] 979 occurrences of tree_code_length[CST] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14840
[Bug tree-optimization/15838] "Inline" value of static struct
--- Additional Comments From kazu at cs dot umass dot edu 2005-05-07 04:48 --- My patch for PR14841 also works for this case. -- What|Removed |Added AssignedTo|dnovillo at gcc dot gnu dot |kazu at cs dot umass dot edu |org | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15838
[Bug middle-end/21433] New: The COMPONENT_REF case of expand_expr_real_1 is probably wrong
We have the following coverage for the COMPONENT_REF case.
-: 6997:case COMPONENT_REF:
-: 6998: /* If the operand is a CONSTRUCTOR, we can just extract
the
-: 6999: appropriate field if it is present. */
75549: 7000: if (TREE_CODE (TREE_OPERAND (exp, 0)) == CONSTRUCTOR)
-: 7001:{
-: 7002: tree elt;
-: 7003:
#: 7004: for (elt = CONSTRUCTOR_ELTS (TREE_OPERAND (exp, 0));
elt;
#: 7005: elt = TREE_CHAIN (elt))
I don't think we should expect a CONSTRUCTOR as the first operand
of EXP. If TREE_OPERAND (exp, 0) is VAR_DECL, then we can expect
CONSTRUCTOR in DECL_INITIAL (TREE_OPERAND (exp, 0)).
--
Summary: The COMPONENT_REF case of expand_expr_real_1 is probably
wrong
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kazu at cs dot umass dot edu
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21433
[Bug tree-optimization/14841] [tree-ssa] const_array[CST] is not folded
--- Additional Comments From kazu at cs dot umass dot edu 2005-05-07 03:08 --- I've extended Steven's patch to handle nested aggregates (i.e. any combination of ARRAY_REF and COMPONENT_REF). -- What|Removed |Added AssignedTo|dnovillo at gcc dot gnu dot |kazu at cs dot umass dot edu |org | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14841
[Bug middle-end/21430] New: Quadratic behavior with constant initializers
Consider:
#define B1(C,D) \
B0(C##0,D##0) B0(C##1,D##0) B0(C##2,D##0) B0(C##3,D##0) B0(C##4,D##0) \
B0(C##5,D##0) B0(C##6,D##0) B0(C##7,D##0) B0(C##8,D##0) B0(C##9,D##0)
#define B2(C,D) \
B1(C##0,D##0) B1(C##1,D##0) B1(C##2,D##0) B1(C##3,D##0) B1(C##4,D##0) \
B1(C##5,D##0) B1(C##6,D##0) B1(C##7,D##0) B1(C##8,D##0) B1(C##9,D##0)
#define B3(C,D) \
B2(C##0,D##0) B2(C##1,D##0) B2(C##2,D##0) B2(C##3,D##0) B2(C##4,D##0) \
B2(C##5,D##0) B2(C##6,D##0) B2(C##7,D##0) B2(C##8,D##0) B2(C##9,D##0)
#define B4(C,D) \
B3(C##0,D##0) B3(C##1,D##0) B3(C##2,D##0) B3(C##3,D##0) B3(C##4,D##0) \
B3(C##5,D##0) B3(C##6,D##0) B3(C##7,D##0) B3(C##8,D##0) B3(C##9,D##0)
#define B0(C,D) C,
const int a[] = { B4(1,1) 0 };
#undef B0
void bar (int);
void
foo (void)
{
#define B0(C,D) bar(a[C-D]);
B4(1,1);
#undef B0
}
Change B4(1,1) to B3(1,1), B2(1,1), etc. You'll get quadratic behavior.
On my machine,
B110 elements 0.097s
B2 100 elements 0.094s
B3 1000 elements 1.373s
B4 1 elements 41.816s
I'm pretty sure the quadratic behavior comes from the ARRAY_REF case of
expand_expr_real_1.
--
Summary: Quadratic behavior with constant initializers
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: compile-time-hog
Severity: normal
Priority: P2
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kazu at cs dot umass dot edu
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21430
[Bug middle-end/21417] Missed jump threading opportunity on trees
-- What|Removed |Added CC||kazu at cs dot umass dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21417
[Bug tree-optimization/21368] New: VRP does not know that &s.a != NULL
Consider
struct s {
int a;
} s;
int
foo (void)
{
int *p = &s.a;
if (p == 0)
return 123;
/* Force VRP to run by having it insert at least one
ASSERT_EXPR. */
*p = 456;
return 0;
}
Note that with -fno-dominator-opts, VRP does not fold the "if" statement.
expr_computes_nonzero could use get_base_address.
--
Summary: VRP does not know that &s.a != NULL
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kazu at cs dot umass dot edu
CC: dnovillo at redhat dot com,gcc-bugs at gcc dot gnu dot
org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21368
[Bug tree-optimization/21367] New: VRP does not fold "if (a == b)" in a certain situation
Consider
int
foo (int a, int b)
{
if (a == b)
if (a == b)
return 123;
return 0;
}
With -fno-tree-dominator-opts -fdump-tree-vrp-details, VRP does not fold
the second "if" statement. Here is what I get from VRP.
Value ranges after VRP:
D.1234_1: VARYING
a_2: VARYING
b_3: VARYING
_4: VARYING
D.1234_5: [0, 0]
D.1234_6: [123, 123]
a_7: [b_3, b_3]
a_8: ~[b_3, b_3]
foo (a, b)
{
int D.1234;
:
if (a_2 == b_3) goto ; else goto ;
:;
a_7 = b_3;
if (a_7 == b_3) goto ; else goto ;
:;
D.1234_6 = 123;
goto ();
:;
a_8 = a_2;
:;
D.1234_5 = 0;
# D.1234_1 = PHI ;
:;
return D.1234_1;
}
Note that we have
b_3: VARYING
a_7: [b_3, b_3]
so we have enough information to fold the second "if" statement despite
the fact that b_3 is VARYING.
--
Summary: VRP does not fold "if (a == b)" in a certain situation
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kazu at cs dot umass dot edu
CC: dnovillo at redhat dot com,gcc-bugs at gcc dot gnu dot
org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21367
[Bug tree-optimization/21348] New: tree-vrp.c:has_assert_expr is useless.
Coverage shows:
-: 1336:/* Return true if OP is the result of an ASSERT_EXPR that tests
the
-: 1337: same condition as COND. */
-: 1338:
-: 1339:static bool
-: 1340:has_assert_expr (tree op, tree cond)
88954: 1341:{
88954: 1342: tree def_stmt = SSA_NAME_DEF_STMT (op);
-: 1343: tree assert_expr, other_cond, other_op;
-: 1344:
-: 1345: /* If OP was not generated by an ASSERT_EXPR, return false.
*/
88954: 1346: if (TREE_CODE (def_stmt) != MODIFY_EXPR
-: 1347: || TREE_CODE (TREE_OPERAND (def_stmt, 1)) != ASSERT_EXPR)
88954: 1348:return false;
-: 1349:
#: 1350: assert_expr = TREE_OPERAND (def_stmt, 1);
#: 1351: other_cond = ASSERT_EXPR_COND (assert_expr);
#: 1352: other_op = ASSERT_EXPR_VAR (assert_expr);
This is because we don't insert ASSERT_EXPR before VRP.
The ASSERT_EXPRs that are inserted by VRP are not noticed by this function
because update_ssa is yet to be called.
--
Summary: tree-vrp.c:has_assert_expr is useless.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kazu at cs dot umass dot edu
CC: dnovillo at redhat dot com,gcc-bugs at gcc dot gnu dot
org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21348
[Bug tree-optimization/21294] Missed removal of null pointer check
--- Additional Comments From kazu at cs dot umass dot edu 2005-05-02 18:07 --- Just checked in a patch. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21294
[Bug tree-optimization/21294] Missed removal of null pointer check
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-30 03:34 --- I've got a patch in testing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21294
[Bug tree-optimization/21294] Missed removal of null pointer check
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |kazu at cs dot umass dot edu |dot org | Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21294
[Bug tree-optimization/21294] Missed removal of null pointer check
-- What|Removed |Added CC||kazu at cs dot umass dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21294
[Bug tree-optimization/21289] New: A numeric range is spoiled by a symblic one in VRP
Consider
int
foo (int a, int b)
{
if (a == 1)
if (a < b)
if (a == 1)
return 1;
return 0;
}
VRP does not remove the third "if" even though 'a' is known to be 1.
This is because the symbolic range obtained from the second "if"
spoils the numeric range [1, 1] obtained from the first "if".
extract_range_from_assert tries to refine a range from an ASSERT_EXPR
if there is another range previously available, but in this case,
VRP cannot prove that [1,1] and [-INF, b-1] intersects,
it does not refine a range.
--
Summary: A numeric range is spoiled by a symblic one in VRP
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kazu at cs dot umass dot edu
CC: dnovillo at redhat dot com,gcc-bugs at gcc dot gnu dot
org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21289
[Bug tree-optimization/21030] [4.1 Regression] ICE in set_value_range building 176.gcc with -O2
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-29 16:27 --- Just checked in a patch. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21030
[Bug tree-optimization/21030] [4.1 Regression] ICE in set_value_range building 176.gcc with -O2
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-29 16:25 --- Just checked in a patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21030
[Bug tree-optimization/21030] [4.1 Regression] ICE in set_value_range building 176.gcc with -O2
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-29 14:55 --- Subject: Re: [4.1 Regression] ICE in set_value_range building 176.gcc with -O2 Hi Diego, > Kazu, did you mail your patch before attaching it to bugzilla? I > haven't received it. The same thing happened to your previous > patch for this PR and I missed it the first time. No, I did not send my previous to gcc-patches@ because I was not fully satified with it. Although I tested the patch, it broke pr18178.C, and I did not analyze the failure at that time. I have not sent my current patch to gcc-patches@ yet because I have not finished testing it. This time I will unless you beat me to it. Kazu Hirata -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21030
[Bug tree-optimization/21030] [4.1 Regression] ICE in set_value_range building 176.gcc with -O2
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-29 14:35 --- Diego, no, I don't mind. But I have a patch whose bootstrap is almost over and regression testing is about to start. This patch does not break g++dg/tree-ssa/pr18178.C unlike my previous patch. Let me attach my patch (and some analysis) just FWIW. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21030
[Bug tree-optimization/21030] [4.1 Regression] ICE in set_value_range building 176.gcc with -O2
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-28 19:33 --- Diego, I think it's OK to have contradictory information from an ASSERT_EXPR and SCEV. Let's say we have a loop counting from i = 0 upward. It's possible that we "if (i < 0)" in the loop and see something like i_10 = ASSERT_EXPR ; on the "then" arm of the conditional. In this case, we know we are counting upward, so SCEV tells us that the minimum value of i_10 should be 0, but the ASSERT_EXPR tells us that the range should be [-INF, -1]. They are completely disjoint! This weird situation comes from the fact that the "then" branch of the conditional is dead. In this case, probably the safest and simplest thing to do is to ignoring what SCEV says. Kazu Hirata -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21030
[Bug tree-optimization/21258] Teach VRP to pick up a constant from case label.
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-28 05:45 --- I'm testing a patch. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |kazu at cs dot umass dot edu |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21258
[Bug tree-optimization/21258] New: Teach VRP to pick up a constant from case label.
Consider:
void bar (void);
void
foo (int a)
{
switch (a)
{
case 4:
if (a >= 3
&& a <= 5)
bar ();
}
}
Note that we could remove the "if" statement, VRP does not catch this.
I think Diego already knows about this, but I think it's worth a PR so that
we don't forget.
--
Summary: Teach VRP to pick up a constant from case label.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kazu at cs dot umass dot edu
CC: dnovillo at redhat dot com,gcc-bugs at gcc dot gnu dot
org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21258
[Bug tree-optimization/21047] ASSERT_EXPR handling in fold never triggers.
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-26 15:18 --- Just checked in a patch. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21047
[Bug tree-optimization/21030] [4.1 Regression] ICE in set_value_range building 176.gcc with -O2
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-24 14:02 --- I just went through the regression testing. I get FAIL: g++.dg/tree-ssa/pr18178.C scan-tree-dump-times if 1 It may be a good idea to check in this patch with the above testcase XFAILed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21030
[Bug middle-end/21180] [4.1 Regression] checking on fold no longer happens in some cases
-- What|Removed |Added Summary|[4.1 Regression] checking on|[4.1 Regression] checking on |fold is no longer happen in |fold no longer happens in |some cases |some cases http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21180
[Bug tree-optimization/21030] [4.1 Regression] ICE in set_value_range building 176.gcc with -O2
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-23 14:13 --- Subject: Re: [4.1 Regression] ICE in set_value_range building 176.gcc with -O2 Hi Toon, > > Kazu, I just tried the patch, pr21030-vrp-ice.patch. > > It seems to fix the problems with gfortran and -O2. > > Kazu, could you propose your patch on gcc-patches or ping it ? Without this > patch I won't be able to do any testing for my GCC Summit paper (deadline 1st > of > May). I would like to, but currently my patch causes a regression in one of the VRP testcases. I have not checked if the failure is a real one or not. That is, it's plausible that we are looking for an optimization that should not happen. Kazu Hirata -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21030
[Bug tree-optimization/21170] New: Comments still mention rewrite_ssa_into_ssa.
tree-ssa-dom.c: rewrite_ssa_into_ssa. tree-ssa-threadupdate.c: SSA_NAMEs. Right now, we just call into rewrite_ssa_into_ssa Note that rewrite_ssa_into_ssa was just removed today. -- Summary: Comments still mention rewrite_ssa_into_ssa. Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P2 Component: tree-optimization AssignedTo: dnovillo at redhat dot com ReportedBy: kazu at cs dot umass dot edu CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21170
[Bug tree-optimization/21088] VRP passes fold the type of operands of a comparison
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-23 02:03 --- Just checked in a patch. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21088
[Bug tree-optimization/21137] New: Convert (a >> 2) & 1 != 0 into a & 4 != 0
At tree level, we would like to canonicalize (a >> 2) & 1 != 0 into a & 4 != 0.
Currently,
void bar (void);
void
foo (int a)
{
if ((a >> 2) & 1)
bar ();
}
turns into
foo (a)
{
int D.1235;
int D.1236;
_Bool D.1237;
D.1235 = a >> 2;
D.1236 = D.1235 & 1;
D.1237 = (_Bool) D.1236;
if (D.1237)
{
bar ();
}
else
{
}
}
--
Summary: Convert (a >> 2) & 1 != 0 into a & 4 != 0
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kazu at cs dot umass dot edu
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21137
[Bug tree-optimization/14847] [tree-ssa] combine "if (a & 1) goto there" and "if (a & 4) goto there"
-- Bug 14847 depends on bug 14846, which changed state. Bug 14846 Summary: [tree-ssa] don't use a shift in A & CST_POWER_OF_2 == 0 until very late in tree-ssa optimizations http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14846 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14847
[Bug tree-optimization/14846] [tree-ssa] don't use a shift in A & CST_POWER_OF_2 == 0 until very late in tree-ssa optimizations
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-21 00:40 --- Just checked in a patch. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14846
[Bug tree-optimization/21116] [4.1 Regression] tree-ssa-phiopt.c:193 has wrong translation from EDGE_COUNT to single_succ_p.
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-20 13:20 --- Just checked in a patch. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21116
[Bug tree-optimization/21116] tree-ssa-phiopt.c:193 has wrong translation from EDGE_COUNT to single_succ_p.
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |kazu at cs dot umass dot edu |dot org | Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21116
[Bug tree-optimization/21116] New: tree-ssa-phiopt.c:193 has wrong translation from EDGE_COUNT to single_succ_p.
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-phiopt.c.diff?r1=2.25&r2=2.26&only_with_tag=MAIN
- if (EDGE_COUNT (bb1->succs) > 1
+ if (!single_succ_p (bb1) > 1
We don't need "> 1".
--
Summary: tree-ssa-phiopt.c:193 has wrong translation from
EDGE_COUNT to single_succ_p.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kazu at cs dot umass dot edu
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21116
[Bug tree-optimization/21096] copy-prop leaks memory
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-19 11:44 --- Just checked in a patch. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21096
[Bug tree-optimization/21096] New: copy-prop leaks memory
tree-ssa-copy.c:844 cached_last_copy_of = xmalloc (...) does not have a corresponding free. Confirmed with valgrind. -- Summary: copy-prop leaks memory Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P2 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kazu at cs dot umass dot edu CC: dnovillo at redhat dot com,gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21096
[Bug tree-optimization/21090] New: VRP does not notice nonzero-ness from a PHI node
Consider:
int g, h;
int
foo (int a)
{
int *p;
if (a)
p = &g;
else
p = &h;
if (p != 0)
return 1;
else
return 0;
}
With -O2 -fno-dominator-opts, VRP does not optimize away the "if" statement.
This is because VRP does not run the propagator when it does not insert
any ASSERT_EXPR.
Even if I force it to run the propagator by forcing vrp_initialize to
return true, the meet function decides that the lattice value of p
at the second "if" statement is VARYING.
I guess we can teach the meet function to generate ~[0, 0] when we meet
&g and &h.
--
Summary: VRP does not notice nonzero-ness from a PHI node
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kazu at cs dot umass dot edu
CC: dnovillo at redhat dot com,gcc-bugs at gcc dot gnu dot
org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21090
[Bug tree-optimization/21088] New: VRP passes fold the type of operands of a comparison
Around tree-vrp.c:420, we have t = fold (build2 (LT_EXPR, TREE_TYPE (val1), val1, val2)); if (t == boolean_true_node) return -1; Since VAL1 is known to be of a pointer type, the result of fold will never be equal to boolean_true_node, which is of the boolean type. -- Summary: VRP passes fold the type of operands of a comparison Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P2 Component: tree-optimization AssignedTo: kazu at cs dot umass dot edu ReportedBy: kazu at cs dot umass dot edu CC: dnovillo at redhat dot com,gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21088
[Bug tree-optimization/21086] New: VRP does not extract a value from a comparison expression.
Consider:
int
foo (int *p)
{
int a = *p;
int b = p != 0;
*p = b;
if (b)
return a;
else
return 0;
}
Here is what I get with -O2 -fno-tree-dominator-opts
foo (p)
{
int b;
int a;
int D.1235;
:
a_3 = *p_2;
p_7 = p_2;
b_4 = p_7 != 0B;
*p_7 = b_4;
p_10 = p_7;
if (b_4 != 0) goto ; else goto ;
:;
a_6 = 0;
# a_1 = PHI ;
:;
return a_1;
}
Note that the "if" statement is not optimized away.
This is because VRP does not extract a value from a comparison expression.
--
Summary: VRP does not extract a value from a comparison
expression.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P2
Component: tree-optimization
AssignedTo: kazu at cs dot umass dot edu
ReportedBy: kazu at cs dot umass dot edu
CC: dnovillo at redhat dot com,gcc-bugs at gcc dot gnu dot
org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21086
[Bug tree-optimization/21001] VRP is weak when the tested variable in a COND_EXPR is used only in the COND_EXPR.
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-18 06:11 --- Just checked in a patch. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21001
[Bug tree-optimization/21021] [4.1 Regression] ICE in tree-vrp building glibc
-- Bug 21021 depends on bug 21024, which changed state. Bug 21024 Summary: fold generates a comparison of two operands whose types do not match http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21024 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21021
[Bug middle-end/21024] fold generates a comparison of two operands whose types do not match
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-17 01:41 --- Just checked in a patch. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21024
[Bug middle-end/21024] fold generates a comparison of two operands whose types do not match
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-16 14:07 --- Patch posted: http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01830.html -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21024
[Bug tree-optimization/21001] VRP is weak when the tested variable in a COND_EXPR is used only in the COND_EXPR.
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-15 20:32 --- Patch posted: http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01770.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21001
[Bug tree-optimization/21031] Another missed forward propagation opportunity
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-15 18:44 --- Just checked in a patch. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21031
[Bug tree-optimization/21047] New: ASSERT_EXPR handling in fold never triggers.
According to tree.def, ASSERT_EXPR belongs to tcc_expression.
When fold gets a tree node that is tcc_expressions,
we do not get to the following switch statement.
switch (code)
{
case CONST_DECL:
return fold (DECL_INITIAL (t));
case ASSERT_EXPR:
So the ASSERT_EXPR case never triggers.
--
Summary: ASSERT_EXPR handling in fold never triggers.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kazu at cs dot umass dot edu
CC: dnovillo at redhat dot com,gcc-bugs at gcc dot gnu dot
org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21047
[Bug c/21024] fold generates a comparison of two operands whose types do not match
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-15 16:37 --- build_binary_op builds a binary tree node for r >= (const void *) *q; Here are the details. (gdb) p resultcode $2 = GE_EXPR (gdb) call debug_tree(build_type) constant invariant 32> unit size constant invariant 4> align 32 symtab 0 alias set -1 precision 32 min max pointer_to_this > (gdb) call debug_tree(op0) > unsigned SI size unit size align 32 symtab 0 alias set -1> used unsigned SI file test.c line 6 size unit size align 32 context initial > (gdb) call debug_tree(op1) > unsigned SI size unit size align 32 symtab 0 alias set -1> arg 0 unit size align 32 symtab 0 alias set -1 precision 32 min max pointer_to_this > arg 0 used unsigned SI file test.c line 4 size unit size align 32 context result initial arg-type arg-type-as-written chain >>> Before the binary tree node is returned to the caller, build_binary_op calls fold to fold the newly built tree node. Since the tree node is a binary one, fold calls fold_binary. fold_binary strips what it considers to be useless type conversion. By the time we get to the case handling GE_EXPR, we have the following operands whose types do not match. (gdb) call debug_tree(arg0) > unsigned SI size unit size align 32 symtab 0 alias set -1> used unsigned SI file test.c line 6 size unit size align 32 context initial > (gdb) call debug_tree(arg1) unit size align 32 symtab 0 alias set -1 precision 32 min max pointer_to_this > arg 0 unsigned SI size unit size align 32 symtab 0 alias set -1> used unsigned SI file test.c line 4 size unit size align 32 context result initial arg-type arg-type-as-written chain unsigned SI file test.c line 4 size unit size align 32 context result initial arg-type arg-type-as-written >>> Note that arg0 is of a pointer type, whereas arg1 is of an integer type. Roger, I don't think it's OK to create this kind of type mismatch. At the very least, that would complicate SSA optimizers. Thoughts? -- What|Removed |Added CC||roger at eyesopen dot com Summary|Type mismatch in a |fold generates a comparison |comparison. |of two operands whose types ||do not match http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21024
[Bug tree-optimization/21031] Another missed forward propagation opportunity
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-15 15:30 --- Patch posted: http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01726.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21031
[Bug tree-optimization/20936] [4.1 Regression] tree check: accessed operand 2 of view_convert_expr with 1 operands
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-15 14:07 --- Just checked in a patch. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20936
[Bug tree-optimization/20936] [4.1 Regression] tree check: accessed operand 2 of view_convert_expr with 1 operands
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-15 04:05 --- Testing the obvious fix. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |kazu at cs dot umass dot edu |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20936
[Bug tree-optimization/21021] [4.1 Regression] ICE in tree-vrp building glibc
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-15 01:31 --- Just checked in a workaround patch. For a real fix, keep an eye on PR 21024. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21021
[Bug tree-optimization/21021] [4.1 Regression] ICE in tree-vrp building glibc
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-14 23:07 --- Patch posted: http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01668.html -- What|Removed |Added CC||dnovillo at gcc dot gnu dot ||org AssignedTo|dnovillo at gcc dot gnu dot |kazu at cs dot umass dot edu |org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21021
