[Bug optimization/14341] New: Missed optimization

[Bug optimization/14341] New: Missed optimization

[pinskia at gcc dot gnu dot org]

The call to f below should just be called with just 1 instead of the extra compares.
void f(int);
int h(int, int);
void t()
{
  int i;
  int x;
    for( i = 0; i < 100000000; i++ ){ 
 	f(i < 100000000);
    }
}

-- 
           Summary: Missed optimization
           Product: gcc
           Version: 3.5.0
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P2
         Component: optimization
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: pinskia at gcc dot gnu dot org
                CC: gcc-bugs at gcc dot gnu dot org


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

[Bug optimization/14341] Missed comparision optimization (jump threading related)

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-02-29 06:37 -------
This should be done on the tree-ssa with the jump threading code, as this code is done 
right:

void f(int);
int h(int, int);

void t()
{
  int i;
  int x;
    for( i = 0; i < 100000000; i++ ){ 
        if (i < 100000000)
 	 f(1);
        else
         f(0);
    }
}
And this one:
void t1()
{
  int i;
  int x;
    for( i = 0; i < 100000000; i++ ){ 
      int t;
      if (i < 100000000) t=1;else t =0;
 	f( t );
    }
}
But note this one is not either:
void t()
{
  int i;
  int x;
    for( i = 0; i < 100000000; i++ ){ 
      int t = ({int i;if (i < 100000000) i=1;else i =0; i;});
 	f( t );
    }
}

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |law at gcc dot gnu dot org
           Keywords|                            |pessimizes-code
      Known to fail|                            |tree-ssa
            Summary|Missed optimization         |Missed comparision
                   |                            |optimization (jump threading
                   |                            |related)
   Target Milestone|---                         |tree-ssa


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

[Bug optimization/14341] Missed comparision optimization (jump threading related)

[steven at gcc dot gnu dot org]

------- Additional Comments From steven at gcc dot gnu dot org  2004-02-29 14:19 -------
Tree dump after DCE1: 
 
t () 
{ 
  int x; 
  int i; 
  int T.0; 
 
  # BLOCK 0 
  # PRED: ENTRY (fallthru) 
  i_2 = 0; 
  goto <bb 2> (<L1>); 
  # SUCC: 2 (fallthru) 
 
  # BLOCK 1 
  # PRED: 2 (true) 
<L0>:; 
  T.0_3 = i_1 <= 99999999; 
  f (T.0_3); 
  i_4 = i_1 + 1; 
  # SUCC: 2 (fallthru) 
 
  # BLOCK 2 
  # PRED: 1 (fallthru) 0 (fallthru) 
  # i_1 = PHI <i_2(0), i_4(1)>; 
<L1>:; 
  if (i_1 <= 99999999) goto <L0>; else goto <L2>; 
  # SUCC: 3 (false) 1 (true) 
 
  # BLOCK 3 
  # PRED: 2 (false) 
<L2>:; 
  return; 
  # SUCC: EXIT 
 
} 
 
The dominator tree looks like this: 
 
bb0 
| 
bb2 (contains loop exit condition "i < 100000000") 
|\ 
| \ 
|  \ 
|   bb1 (contains "f(i < 100000000);") 
| 
bb3 
 
So the loop exit condition dominates the function call and we should be able 
to optimize that test. 
 
 
 
Tree dump after DOM1: 
 
t () 
{ 
  int x; 
  int i; 
  int T.0; 
 
  # BLOCK 0 
  # PRED: ENTRY (fallthru) 
  i_5 = 0; 
  i_6 = 0; 
  # SUCC: 1 (fallthru) 
 
  # BLOCK 1 
  # PRED: 0 (fallthru) 1 (true) 
  # i_1 = PHI <0(0), i_7(1)>; 
<L0>:; 
  T.0_3 = i_1 <= 99999999; 
  f (T.0_3); 
  i_7 = i_1 + 1; 
  if (i_7 <= 99999999) goto <L0>; else goto <L2>; 
  # SUCC: 2 (false) 1 (true) 
 
  # BLOCK 2 
  # PRED: 1 (false) 
<L2>:; 
  return; 
  # SUCC: EXIT 
 
} 
 
 
The dominator tree looks like this: 
 
bb0 
| 
bb1 (contains loop exit condition "i < 100000000" 
|    and "f(i < 100000000);") 
| 
bb3 
 
So the loop exit condition no longer dominates the function call, and we lose. 
 
So perhaps we are threading jumps too early. 

-- 


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

[Bug optimization/14341] Missed comparision optimization (jump threading related)

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-02-29 16:15 -------
Confirmed by Stevenb.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2004-02-29 16:15:35
               date|                            |


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

[Bug optimization/14341] Missed comparision optimization (jump threading related)

[law at redhat dot com]

------- Additional Comments From law at redhat dot com  2004-03-01 04:28 -------
Subject: Re:  Missed comparision optimization (jump 
 threading related)

In message <20040229142002.10721.qmail@sources.redhat.com>, "steven at gcc dot 
gnu dot org" writes:
 >
 >------- Additional Comments From steven at gcc dot gnu dot org  2004-02-29 14
 >:19 -------
 >Tree dump after DCE1: 
 > 
 >t () 
 >{ 
 >  int x; 
 >  int i; 
 >  int T.0; 
 > 
 >  # BLOCK 0 
 >  # PRED: ENTRY (fallthru) 
 >  i_2 = 0; 
 >  goto <bb 2> (<L1>); 
 >  # SUCC: 2 (fallthru) 
 > 
 >  # BLOCK 1 
 >  # PRED: 2 (true) 
 ><L0>:; 
 >  T.0_3 = i_1 <= 99999999; 
 >  f (T.0_3); 
 >  i_4 = i_1 + 1; 
 >  # SUCC: 2 (fallthru) 
 > 
 >  # BLOCK 2 
 >  # PRED: 1 (fallthru) 0 (fallthru) 
 >  # i_1 = PHI <i_2(0), i_4(1)>; 
 ><L1>:; 
 >  if (i_1 <= 99999999) goto <L0>; else goto <L2>; 
 >  # SUCC: 3 (false) 1 (true) 
 > 
 >  # BLOCK 3 
 >  # PRED: 2 (false) 
 ><L2>:; 
 >  return; 
 >  # SUCC: EXIT 
 > 
 >} 
 > 
 >The dominator tree looks like this: 
 > 
 >bb0 
 >| 
 >bb2 (contains loop exit condition "i < 100000000") 
 >|\ 
 >| \ 
 >|  \ 
 >|   bb1 (contains "f(i < 100000000);") 
 >| 
 >bb3 
 > 
 >So the loop exit condition dominates the function call and we should be able 
 >to optimize that test. 
But what the tree dumps don't show is that the types of those expressions
are fundamentally different.  So while it may appear that the expressions
are the same, they are, from the compiler's standpoint different.

In the stagement "T.0_3 = i_1 <= 99999999"

The expression i_1 <= 99999999 has a signed integer type as mandated by
the C standard.

In the statement "if (i1 <= 99999999) ..." the expression i1 <= 99999999
has a boolean type.

Those types differ in significant ways.  They differ in signedness, their
underlying modes and width of the datatype.

The compiler has to be extremely careful when creating equivalences for
objects which have types which differ in these ways.  In this specific case,
both types are integers and the range of the expression they generate is 0..1
inclusive, so there may be something we can do.  Then again, this may prove
too intrusive and ugly to try and fix.

In general, the first thing to do anytime you see a seemingly redundant
expression that is not eliminated is to verify that the underlying types
of the expressions are equivalent.

Jeff



-- 


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

[Bug optimization/14341] Missed comparision optimization (jump threading related)

[law at gcc dot gnu dot org]

------- Additional Comments From law at gcc dot gnu dot org  2004-03-01 14:37 -------
Fixed with today's checkin to tree-ssa-dom.c

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


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

[Bug optimization/14341] Missed comparision optimization (jump threading related)

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-03-07 04:51 -------
Reopening as it is only fixed on the branch and not the mainline yet.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |


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

[Bug optimization/14341] Missed comparision optimization (jump threading related)

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-03-07 04:52 -------
suspending as it is fixed on the tree-ssa.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |SUSPENDED


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

[Bug tree-optimization/14341] Missed comparision optimization (jump threading related)

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-05-13 11:40 -------
Note fixed by the tree-ssa.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|SUSPENDED                   |NEW
          Component|rtl-optimization            |tree-optimization
   Last reconfirmed|2004-02-29 16:15:35         |2004-05-13 11:40:52
               date|                            |
   Target Milestone|tree-ssa                    |3.5.0


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

[Bug tree-optimization/14341] Missed comparision optimization (jump threading related)

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|3.5.0                       |---


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

[Bug tree-optimization/14341] Missed comparision optimization (jump threading related)

[kazu at cs dot umass dot edu]

------- Additional Comments From kazu at cs dot umass dot edu  2004-12-22 05:23 -------
The first two testcases seem to be OK.  All calls to f are f(1).

The last testcase is probably not what Andrew had in mind.
Specifically, "i" in the innermost scope isn't initialized.

Andrew, can you confirm (and close if you think these are fixed)?


-- 


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

[Bug tree-optimization/14341] Missed comparision optimization (jump threading related)

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-22 05:33 -------
(In reply to comment #9)
> The first two testcases seem to be OK.  All calls to f are f(1).
> 
> The last testcase is probably not what Andrew had in mind.
> Specifically, "i" in the innermost scope isn't initialized.
> 
> Andrew, can you confirm (and close if you think these are fixed)?

It is not fixed for me on PPC:
        cmpw cr7,r30,r28
        crnot 30,29
        mfcr r3
        rlwinm r3,r3,31,1
        bl L_f$stub

r3 is where the first argrument is stored.

but you are right about the last testcase being wrong.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
 GCC target triplet|                            |powerpc-darwin


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

[Bug tree-optimization/14341] Missed comparision optimization (jump threading related)

[law at redhat dot com]

------- Additional Comments From law at redhat dot com  2004-12-23 18:32 -------
Subject: Re:  Missed comparision optimization
	(jump threading related)

On Wed, 2004-12-22 at 05:33 +0000, pinskia at gcc dot gnu dot org wrote:
> ------- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-22 05:33 -------
> (In reply to comment #9)
> > The first two testcases seem to be OK.  All calls to f are f(1).
> > 
> > The last testcase is probably not what Andrew had in mind.
> > Specifically, "i" in the innermost scope isn't initialized.
> > 
> > Andrew, can you confirm (and close if you think these are fixed)?
> 
> It is not fixed for me on PPC:
>         cmpw cr7,r30,r28
>         crnot 30,29
>         mfcr r3
>         rlwinm r3,r3,31,1
>         bl L_f$stub
> 
> r3 is where the first argrument is stored.
> 
> but you are right about the last testcase being wrong.
Hmmm, something must have changed since it doesn't look like the jump
is being threaded anymore on ia32 either.

Let's keep this one open, but odds are it needs to be targeted at 4.1.

jeff




-- 


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

[Bug tree-optimization/14341] Missed comparision optimization (jump threading related)

[kazu at cs dot umass dot edu]

------- Additional Comments From kazu at cs dot umass dot edu  2005-01-31 14:03 -------
The first two cases are optimized as expected.

The third one is wrong.  Here is mostly likely what Andrew Pinski meant to say.

void
t2 ()
{
  int i;
  int x;
  for (i = 0; i < 100000000; i++)
    {
      int t = (
      {
	int j = i;

	if (j < 100000000)
	  j = 1;
	else
	  j = 0;
	j;
      }
      );
      f (t);
    }
}

which is again optimized as optimized.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


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

[Bug tree-optimization/14341] Missed comparision optimization (jump threading related)

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-31 14:46 -------
No, the first one is not even optimizated on the mainline on ppc:
        cmpw cr7,r30,r28
        crnot 30,29
        mfcr r3
        rlwinm r3,r3,31,1
        bl L_f$stub


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |


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

[Bug tree-optimization/14341] Missed comparison optimization (jump threading related)

[kazu at cs dot umass dot edu]

------- Additional Comments From kazu at cs dot umass dot edu  2005-01-31 15:25 -------
Subject: Re:  Missed comparision optimization
 (jump threading related)

Hi Andrew,

> No, the first one is not even optimizated on the mainline on ppc:
>         cmpw cr7,r30,r28
>         crnot 30,29
>         mfcr r3
>         rlwinm r3,r3,31,1
>         bl L_f$stub

Could you post your tree dump?  This PR is supposed to be about tree
optimization.  If that is not true on PPC, you might want to change
this to rtl-optimization or something more appropriate.

As far as I can tell, tree dumps look OK for all test cases (with the
third one repaired).

Kazu Hirata


-- 


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

[Bug tree-optimization/14341] Missed comparison optimization (jump threading related)

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-31 15:33 -------
<L0>:;
  f (i <= 99999999);
  D.1141 = (unsigned int) i + 1;
  i = (int) D.1141;
  if (D.1141 != 100000000) goto <L0>; else goto <L2>;

But note on x86 I get the same and the extra compare:
.L2:
        xorl    %eax, %eax
        cmpl    $99999999, %ebx  <--- here
        setle   %al
        movl    %eax, (%esp)
        call    f
        leal    1(%ebx), %eax
        cmpl    $100000000, %eax
        movl    %eax, %ebx
        jne     .L2

I have no idea what is going wrong.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |NEW


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

[Bug tree-optimization/14341] Missed comparison optimization (jump threading related)

[kazu at cs dot umass dot edu]

------- Additional Comments From kazu at cs dot umass dot edu  2005-01-31 15:42 -------
On my x86 machine, I get f (1).

On Andrew's powerpc, he gets f (i < 1000000) regardless of whether he is
targetting x86 or powerpc.

So it might be the case that the host matters.

How strange!?


-- 


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

[Bug tree-optimization/14341] Missed comparison optimization (VRP)

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-07 19:30 -------
Huh, I don't understand why VRP does not take care of this:
i_13: [-2147483648, 99999999]
  D.1236_4 = i_13 <= 99999999;


  i_13 = ASSERT_EXPR <i_1, i_1 <= 99999999>;
  D.1236_4 = i_13 <= 99999999;


The following is the testcase which I used with -O2 -fno-tree-dominator-opts, otherwise VRP is not 
run:
void f(int);
int h(int, int);
void t(int *ttt)
{
  int i;
  int x;
  *ttt  = 1;
if (ttt== 0)
  f(0);
    for( i = 0; i < 100000000; i++ ){
        f(i < 100000000);
    }

}

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dnovillo at gcc dot gnu dot
                   |                            |org
            Summary|Missed comparison           |Missed comparison
                   |optimization (jump threading|optimization (VRP)
                   |related)                    |


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

[Bug tree-optimization/14341] Missed comparison optimization (VRP)

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-06-02 02:57 -------
Subject: Bug 14341

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	dnovillo@gcc.gnu.org	2005-06-02 02:57:15

Modified files:
	gcc            : ChangeLog fold-const.c tree-flow.h 
	                 tree-ssa-ccp.c tree-ssa-copy.c 
	                 tree-ssa-propagate.c tree-ssa-propagate.h 
	                 tree-vrp.c tree.h 
	gcc/testsuite  : ChangeLog 
	gcc/testsuite/gcc.dg/tree-ssa: pr14841.c pr21658.c 
Added files:
	gcc/testsuite/gcc.dg/tree-ssa: pr14341.c pr20701.c pr21029.c 
	                               pr21086.c pr21090.c pr21332.c 
	                               pr21458.c vrp01.c vrp02.c vrp03.c 
	                               vrp04.c vrp05.c vrp06.c vrp07.c 
	                               vrp08.c vrp09.c vrp10.c vrp11.c 
	                               vrp12.c vrp13.c 

Log message:
	2005-06-01  Diego Novillo  <dnovillo@redhat.com>
	
	PR 14341, PR 21332, PR 20701, PR 21029, PR 21086, PR 21090
	PR 21289, PR 21348, PR 21367, PR 21368, PR 21458.
	* fold-const.c (invert_tree_comparison): Make extern.
	* tree-flow.h (enum value_range_type): Move to tree-ssa-propagate.
	(struct value_range_def): Limewise.
	(get_value_range): Remove.
	(dump_value_range): Remove.
	(dump_all_value_ranges): Remove.
	(debug_all_value_ranges): Remove.
	(vrp_evaluate_conditional): Declare.
	* tree-ssa-propagate.c (struct prop_stats_d): Add field
	num_pred_folded.
	(substitute_and_fold): Add argument use_ranges_p.
	Update all callers.
	If use_ranges_p is true, call fold_predicate_in to fold
	predicates using range information.
	Ignore ASSERT_EXPRs.
	Change debugging output to only show statements that have been
	folded.
	(replace_phi_args_in): Move debugging output code from
	substitute and fold.
	(fold_predicate_in): New local function.
	* tree-ssa-propagate.h (enum value_range_type): Move from
	tree-flow.h.
	(struct value_range_d): Likewise.
	Add field 'equiv'.
	(value_range_t): Rename from value_range.
	* tree-vrp.c (found_in_subgraph): Rename from found.
	(get_opposite_operand): Remove.
	(struct assert_locus_d): Declare.
	(assert_locus_t): Declare.
	(need_assert_for): Declare.
	(asserts_for): Declare.
	(blocks_visited): Declare.
	(vr_value): Declare.
	(set_value_range): Add argument 'equiv'.
	Don't drop to VARYING ranges that cover all values in the
	type.
	Make deep copy of equivalence set 'equiv'.
	(copy_value_range): New local function.
	(set_value_range_to_undefined): New local function.
	(compare_values): Return -2 if either value has overflowed.
	(range_includes_zero_p): New local function.
	(extract_range_from_assert): Flip the predicate code if the
	name being asserted is on the RHS of the predicate.
	Avoid creating unnecessary symbolic ranges if the comparison
	includes another name with a known numeric range.
	Update the equivalnce set of the new range when asserting
	EQ_EXPR predicates.
	(extract_range_from_ssa_name): Update the equivalence set of
	the new range with VAR.
	(extract_range_from_binary_expr): Also handle TRUTH_*_EXPR.
	If -fwrapv is used, set the resulting range to VARYING if the
	operation overflows.  Otherwise, use TYPE_MIN_VALUE and
	TYPE_MAX_VALUE to represent -INF and +INF.
	Fix handling of *_DIV_EXPR.
	(extract_range_from_unary_expr): Handle MINUS_EXPR and
	ABS_EXPR properly by switching the range around if necessary.
	(extract_range_from_comparison): New local function.
	(extract_range_from_expr): Call it.
	(adjust_range_with_scev): Do not adjust the range if using
	wrapping arithmetic (-fwrapv).
	(dump_value_range): Also show equivalence set.
	Show -INF and +INF for TYPE_MIN_VALUE and TYPE_MAX_VALUE.
	(build_assert_expr_for): Also build ASSERT_EXPR for EQ_EXPR.
	(infer_value_range): Change return value to bool.
	Add arguments 'comp_code_p' and 'val_p'.
	Do not attempt to infer ranges from statements that may throw.
	Store the comparison code in comp_code_p.
	Store the other operand to be used in the predicate in val_p.
	(dump_asserts_for): New.
	(debug_asserts_for): New.
	(dump_all_asserts): New.
	(debug_all_asserts): New.
	(register_new_assert_for): New.
	(register_edge_assert_for): New.
	(find_conditional_asserts): New.
	(find_assert_locations): New.
	(process_assert_insertions_for): New.
	(process_assert_insertions): New.
	(insert_range_assertions): Initialize found_in_subgraph,
	blocks_visited, need_assert_for and asserts_for.
	Call find_assert_locations and process_assert_insertions.
	(remove_range_assertions): Add more documentation.
	(vrp_initialize): Change return type to void.
	Do not try to guess if running VRP is worth it.
	(compare_name_with_value): New.
	(compare_names): New.
	(vrp_evaluate_conditional): Add argument 'use_equiv_p'.  If
	use_equiv_p is true, call compare_names and
	compare_name_with_value to compare all the ranges for every
	name in the equivalence set of the predicate operands.
	Update all callers.
	(vrp_meet): Try harder not to derive a VARYING range.
	If two values meet, the resulting equivalence set is the
	intersection of the two equivalence sets.
	(vrp_visit_phi_node): Call copy_value_range to get the current
	range information of the LHS.
	(vrp_finalize): Create a value vector representing all the
	names that ended up with exactly one value in their range.
	Call substitute_and_fold.
	(execute_vrp): Document equivalence sets in ranges.
	* tree.h (SSA_NAME_VALUE_RANGE): Remove.
	(struct tree_ssa_name): Remove field value_range.
	(invert_tree_comparison): Declare.
	
	testsuite/ChangeLog
	
	2005-06-01  Diego Novillo  <dnovillo@redhat.com>
	
	PR 14341, PR 21332, PR 20701, PR 21086, PR 21090
	PR 21289, PR 21348, PR 21367, PR 21368, PR 21458.
	* gcc.dg/tree-ssa/pr14341.c: New test.
	* gcc.dg/tree-ssa/pr14841.c: New test.
	* gcc.dg/tree-ssa/pr20701.c: New test.
	* gcc.dg/tree-ssa/pr21086.c: New test.
	* gcc.dg/tree-ssa/pr21090.c: New test.
	* gcc.dg/tree-ssa/pr21332.c: New test.
	* gcc.dg/tree-ssa/pr21458.c: New test.
	* gcc.dg/tree-ssa/pr21658.c: New test.
	* gcc.dg/tree-ssa/vrp01.c: New test.
	* gcc.dg/tree-ssa/vrp02.c: New test.
	* gcc.dg/tree-ssa/vrp03.c: New test.
	* gcc.dg/tree-ssa/vrp04.c: New test.
	* gcc.dg/tree-ssa/vrp05.c: New test.
	* gcc.dg/tree-ssa/vrp06.c: New test.
	* gcc.dg/tree-ssa/vrp07.c: New test.
	* gcc.dg/tree-ssa/vrp08.c: New test.
	* gcc.dg/tree-ssa/vrp09.c: New test.
	* gcc.dg/tree-ssa/vrp10.c: New test.
	* gcc.dg/tree-ssa/vrp11.c: New test.
	* gcc.dg/tree-ssa/vrp12.c: New test.
	* gcc.dg/tree-ssa/vrp13.c: New test.
	
	2005-06-01  Alexandre Oliva  <aoliva@redhat.com>
	
	PR 21029
	* gcc.dg/tree-ssa/pr21029.c: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8989&r2=2.8990
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fold-const.c.diff?cvsroot=gcc&r1=1.589&r2=1.590
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-flow.h.diff?cvsroot=gcc&r1=2.114&r2=2.115
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-ccp.c.diff?cvsroot=gcc&r1=2.77&r2=2.78
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-copy.c.diff?cvsroot=gcc&r1=2.32&r2=2.33
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-propagate.c.diff?cvsroot=gcc&r1=2.22&r2=2.23
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-propagate.h.diff?cvsroot=gcc&r1=2.3&r2=2.4
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-vrp.c.diff?cvsroot=gcc&r1=2.18&r2=2.19
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree.h.diff?cvsroot=gcc&r1=1.732&r2=1.733
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5574&r2=1.5575
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/pr14341.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/pr20701.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/pr21029.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/pr21086.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/pr21090.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/pr21332.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/pr21458.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/vrp01.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/vrp02.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/vrp03.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/vrp04.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/vrp05.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/vrp06.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/vrp07.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/vrp08.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/vrp09.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/vrp10.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/vrp11.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/vrp12.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/vrp13.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/pr14841.c.diff?cvsroot=gcc&r1=1.1&r2=1.2
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/pr21658.c.diff?cvsroot=gcc&r1=1.1&r2=1.2



-- 


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

[Bug tree-optimization/14341] Missed comparison optimization (VRP)

[dnovillo at gcc dot gnu dot org]

------- Additional Comments From dnovillo at gcc dot gnu dot org  2005-06-02 03:03 -------

Fixed.  http://gcc.gnu.org/ml/gcc-patches/2005-06/msg00127.html

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


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

[Bug tree-optimization/14341] Missed comparison optimization (VRP)

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.1.0


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

[Bug tree-optimization/14341] Missed comparison optimization (VRP)

[pinskia at gcc dot gnu dot org]

-- 
Bug 14341 depends on bug 18373, which changed state.

Bug 18373 Summary: [meta-bug] VRP Value Range Propagation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18373

           What    |Old Value                   |New Value
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

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