--- Comment #15 from rakdver at gcc dot gnu dot org 2006-04-09 23:51
---
(In reply to comment #14)
> (In reply to comment #11)
> > I updated the patch for current mainline, but it still has issues for some
> > common uses of loops:
> >
> > void foo(
--- Comment #16 from rakdver at gcc dot gnu dot org 2006-04-10 00:03
---
Created an attachment (id=11231)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11231&action=view)
Updated version of the patch, also handling invariant memory references
--
http://gcc.gnu.org/b
--- Comment #33 from rakdver at gcc dot gnu dot org 2006-04-12 12:20
---
Created an attachment (id=11248)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11248&action=view)
Patch to speed up update_ssa
This patch makes update_ssa significantly faster in cases like thi
--- Comment #37 from rakdver at gcc dot gnu dot org 2006-04-14 00:06
---
Created an attachment (id=11262)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11262&action=view)
Updated version of the patch
This patch (this time more or less a final version, bootstrapped & r
--- Comment #6 from rakdver at gcc dot gnu dot org 2006-04-19 16:32 ---
I do not think this PR is invalid:
int a[100];
int *p = &a[50];
p - 1 is well defined, and points to 50 - 1 th element of a, as standard
specifies
p + (-1) is also well defined, and points to 50 + (-1) th ele
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot
|dot org
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot
|dot org
--- Comment #4 from rakdver at gcc dot gnu dot org 2006-04-27 15:00 ---
Patch:
http://gcc.gnu.org/ml/gcc-patches/2006-04/msg01044.html
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot
|dot org
--- Comment #5 from rakdver at gcc dot gnu dot org 2006-04-27 17:42 ---
This is more or less dup of PR23434 (the fix for it is not quite correct). I am
testing a patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27144
--- Comment #5 from rakdver at gcc dot gnu dot org 2006-04-27 22:21 ---
Patch:
http://gcc.gnu.org/ml/gcc-patches/2006-04/msg01058.html
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from rakdver at gcc dot gnu dot org 2006-04-28 08:44 ---
Patch:
http://gcc.gnu.org/ml/gcc-patches/2006-04/msg01078.html
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from rakdver at gcc dot gnu dot org 2006-05-01 19:42 ---
Subject: Bug 27144
Author: rakdver
Date: Mon May 1 19:42:01 2006
New Revision: 113425
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113425
Log:
PR tree-optimization/27144
* tree-
--- Comment #5 from rakdver at gcc dot gnu dot org 2006-05-01 20:06 ---
Subject: Bug 27283
Author: rakdver
Date: Mon May 1 20:05:57 2006
New Revision: 113427
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113427
Log:
PR tree-optimization/27283
* tree-
--- Comment #6 from rakdver at gcc dot gnu dot org 2006-05-01 20:46 ---
Subject: Bug 27291
Author: rakdver
Date: Mon May 1 20:46:22 2006
New Revision: 113430
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113430
Log:
PR rtl-optimization/27291
* loop-
--- Comment #22 from rakdver at gcc dot gnu dot org 2006-05-02 07:56
---
(In reply to comment #14)
> Hmm, I wonder if the following loop in scev_probably_wraps_p is wrong.
>
> estimate_numbers_of_iterations_loop (loop);
> for (bound = loop->bounds; bound; boun
--- Comment #23 from rakdver at gcc dot gnu dot org 2006-05-02 08:57
---
Somehow, we record that the loop iterates at most once, which obviously leads
to problems.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26304
--- Comment #11 from rakdver at gcc dot gnu dot org 2006-05-02 12:42
---
The problem is that unsigned_type_for returns a size_type for pointers, and
that happens to be signed for fortran. I am not sure whether this is not a bug
in fortran frontend -- I think some places in gcc assume
--- Comment #9 from rakdver at gcc dot gnu dot org 2006-05-04 10:49 ---
Fixed.
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot
|dot org
--- Comment #24 from rakdver at gcc dot gnu dot org 2006-05-08 11:18
---
Patch: http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00290.html
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rakdver at gcc dot gnu dot org 2006-05-08 17:33 ---
Patch: http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00308.html
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rakdver at gcc dot gnu dot org 2006-05-09 09:10 ---
Subject: Bug 27335
Author: rakdver
Date: Tue May 9 09:10:15 2006
New Revision: 113648
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113648
Log:
PR rtl-optimization/27335
* loop-
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot
|dot org
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot
|dot org
--- Comment #2 from rakdver at gcc dot gnu dot org 2006-05-11 14:19 ---
Patch: http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00463.html
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rakdver at gcc dot gnu dot org 2006-05-12 14:46 ---
Can also be reproduced on i686.
Patch: http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00511.html
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rakdver at gcc dot gnu dot org 2006-05-13 19:46 ---
Subject: Bug 27003
Author: rakdver
Date: Sat May 13 19:45:56 2006
New Revision: 113742
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113742
Log:
PR tree-optimization/27003
--- Comment #7 from rakdver at gcc dot gnu dot org 2006-05-13 22:11 ---
Subject: Bug 27335
Author: rakdver
Date: Sat May 13 22:10:56 2006
New Revision: 113746
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113746
Log:
PR rtl-optimization/27335
* loop-
--- Comment #8 from rakdver at gcc dot gnu dot org 2006-05-13 22:12 ---
Subject: Bug 27335
Author: rakdver
Date: Sat May 13 22:12:13 2006
New Revision: 113747
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113747
Log:
PR rtl-optimization/27335
* loop-
--- Comment #7 from rakdver at gcc dot gnu dot org 2006-05-14 14:49 ---
(In reply to comment #4)
> Created an attachment (id=11146)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11146&action=view) [edit]
> first step
>
> with this patch scev returns (int) (cha
--- Comment #38 from rakdver at gcc dot gnu dot org 2006-05-15 18:25
---
Subject: Bug 26830
Author: rakdver
Date: Mon May 15 18:24:55 2006
New Revision: 113799
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113799
Log:
PR tree-optimization/26830
* t
--- Comment #39 from rakdver at gcc dot gnu dot org 2006-05-15 21:56
---
Most of the time is now spent in global alloc (30% of wall time) and rtl loop
invariant motion (also about 30%). Almost all the time of rtl lim is in df
analysis.
--
rakdver at gcc dot gnu dot org changed
--- Comment #8 from rakdver at gcc dot gnu dot org 2006-05-17 11:33 ---
Subject: Bug 27548
Author: rakdver
Date: Wed May 17 11:33:00 2006
New Revision: 113853
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113853
Log:
PR tree-optimization/27548
* tre
--- Comment #4 from rakdver at gcc dot gnu dot org 2006-05-17 13:02 ---
(In reply to comment #2)
> scev_probably_wraps_p returns false because we recorded a max of 49 iteration
> from
>
> (gdb) call debug_generic_expr ( loop->bounds->next->at_stmt)
> D.1993_1
--- Comment #8 from rakdver at gcc dot gnu dot org 2006-05-17 13:11 ---
> It's
>
> (set_scalar_evolution
> (scalar = D.1993_10)
> (scalar_evolution = {79, +, -1}_1))
> )
Then it is a bug in chrec_convert (might also be related to PR 27619).
--
http
--- Comment #9 from rakdver at gcc dot gnu dot org 2006-05-17 13:12 ---
(In reply to comment #8)
> > It's
> >
> > (set_scalar_evolution
> > (scalar = D.1993_10)
> > (scalar_evolution = {79, +, -1}_1))
> > )
>
>
> Then it is a
--- Comment #14 from rakdver at gcc dot gnu dot org 2006-05-17 13:40
---
(In reply to comment #12)
> Ok, the patch fixes this PR, but not PR26719.
>
> Index: tree-chrec.c
> ===
> --- tree-chrec.c(
--- Comment #17 from rakdver at gcc dot gnu dot org 2006-05-17 13:54
---
(In reply to comment #16)
> (bugzilla doesn't like my mail-replies it seems)
>
> Currently we have a type-mismatch type vs. ct, where ct is the canonical type
> for step/base. I guess this
--- Comment #8 from rakdver at gcc dot gnu dot org 2006-05-20 19:27 ---
Patch: http://gcc.gnu.org/ml/gcc-patches/2006-05/msg01032.html
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #24 from rakdver at gcc dot gnu dot org 2006-05-20 19:27
---
Patch: http://gcc.gnu.org/ml/gcc-patches/2006-05/msg01032.html
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot
|dot org
--- Comment #4 from rakdver at gcc dot gnu dot org 2006-05-24 09:54 ---
Patch: http://gcc.gnu.org/ml/gcc-patches/2006-05/msg01229.html
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #25 from rakdver at gcc dot gnu dot org 2006-05-24 22:55
---
Subject: Bug 27639
Author: rakdver
Date: Wed May 24 22:55:15 2006
New Revision: 114057
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114057
Log:
PR tree-optimization/27639
--- Comment #9 from rakdver at gcc dot gnu dot org 2006-05-24 22:55 ---
Subject: Bug 26719
Author: rakdver
Date: Wed May 24 22:55:15 2006
New Revision: 114057
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114057
Log:
PR tree-optimization/27639
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rakdver at gcc dot gnu dot org
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27782
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot
|dot org
--- Comment #7 from rakdver at gcc dot gnu dot org 2006-05-30 12:33 ---
Patch: http://gcc.gnu.org/ml/gcc-patches/2006-05/msg01515.html
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from rakdver at gcc dot gnu dot org 2006-05-30 13:21 ---
Subject: Bug 27779
Author: rakdver
Date: Tue May 30 13:21:06 2006
New Revision: 114233
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114233
Log:
PR tree-optimization/27779
* tree-da
--- Comment #2 from rakdver at gcc dot gnu dot org 2006-06-05 15:19 ---
(In reply to comment #1)
> Can you try the patch linked from PR 27735 to see if this fixes this bug also?
No, this is unrelated (the ice here is from tree_unroll_loop, never gets to
unswitching).
--
rakdver
--- Comment #3 from rakdver at gcc dot gnu dot org 2006-06-06 09:02 ---
Patch: http://gcc.gnu.org/ml/gcc-patches/2006-06/msg00284.html
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot
|dot org
--- Comment #7 from rakdver at gcc dot gnu dot org 2006-06-06 17:19 ---
Patch: http://gcc.gnu.org/ml/gcc-patches/2006-06/msg00313.html
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from rakdver at gcc dot gnu dot org 2006-06-08 08:17 ---
Subject: Bug 26449
Author: rakdver
Date: Thu Jun 8 08:17:05 2006
New Revision: 114481
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114481
Log:
PR rtl-optimization/26449
* loop-inv
--- Comment #4 from rakdver at gcc dot gnu dot org 2006-06-08 08:20 ---
Subject: Bug 27872
Author: rakdver
Date: Thu Jun 8 08:19:50 2006
New Revision: 114482
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114482
Log:
PR tree-optimization/27872
* tree-
--- Comment #2 from rakdver at gcc dot gnu dot org 2006-06-13 14:09 ---
(In reply to comment #1)
> Hmm, it should have produced G.3, G.n, at least I would have thought.
>
No, we intentionally use the same variable for the lexically identical
expressions, see internal_get_t
--- Comment #10 from rakdver at gcc dot gnu dot org 2006-06-15 11:17
---
Hello,
> > http://gcc.gnu.org/ml/gcc-testresults/2006-06/msg00241.html suggests we
> > still
> > have the bug. Can someone confirm this still passes with
> > -fno-move-loop-invariants?
&g
--- Comment #8 from rakdver at gcc dot gnu dot org 2006-06-15 11:31 ---
Ccing people responsible for data dependence analysis. I have hacked this over
on predcom branch, but I would prefer if someone who understands the code could
fix it properly.
--
rakdver at gcc dot gnu dot org
--- Comment #13 from rakdver at gcc dot gnu dot org 2006-06-20 10:26
---
Subject: Bug 27331
Author: rakdver
Date: Tue Jun 20 10:26:45 2006
New Revision: 114810
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114810
Log:
PR tree-optimization/27331
* t
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot
|dot org
--- Comment #16 from rakdver at gcc dot gnu dot org 2006-06-20 14:26
---
Could you please send the .loop2_invariant dump (-dL) ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26244
--- Comment #4 from rakdver at gcc dot gnu dot org 2006-06-21 14:26 ---
On i686-linux, it fails.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28121
--- Comment #5 from rakdver at gcc dot gnu dot org 2006-06-21 14:37 ---
The problem is that the edge from bb 2 has EDGE_EXECUTABLE flag set, which
confuses verify_flow_info.
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from rakdver at gcc dot gnu dot org 2006-06-21 23:15 ---
Patch: http://gcc.gnu.org/ml/gcc-patches/2006-06/msg01215.html
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #19 from rakdver at gcc dot gnu dot org 2006-06-22 10:28
---
The transformations in the invariant motion pass look correct to me, as well as
the code immediately after it. Maybe it is a latent bug in some of the later
passes, but the code produced for the shift is looong
--- Comment #7 from rakdver at gcc dot gnu dot org 2006-06-22 17:54 ---
Subject: Bug 28121
Author: rakdver
Date: Thu Jun 22 17:54:45 2006
New Revision: 114898
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114898
Log:
PR rtl-optimization/28121
* cfg
--- Comment #6 from rakdver at gcc dot gnu dot org 2006-07-12 23:13 ---
Loop header copying is OK; the result is the one I would expect, it certainly
does not make the code worse (unless you are optimizing for code size), and in
many cases may make it better.
I will have a look at the
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot
|dot org
--- Comment #13 from rakdver at gcc dot gnu dot org 2006-07-17 11:54
---
(In reply to comment #12)
> The test case in comment #11 looks like a classic store motion opportunity to
> me. GCC 3.3 performs the store motion, GCC 4.2 r115467 does not.
>
> Zdenek, I thought
--- Comment #2 from rakdver at gcc dot gnu dot org 2008-11-12 04:32 ---
Patch: http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00506.html
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rakdver at gcc dot gnu dot org 2008-11-16 04:49 ---
Subject: Bug 37950
Author: rakdver
Date: Sun Nov 16 04:48:25 2008
New Revision: 141911
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141911
Log:
PR tree-optimization/37950
* t
--- Comment #22 from rakdver at gcc dot gnu dot org 2008-11-17 03:44
---
(In reply to comment #20)
> To add to comment #18, after r128272 GCC for powerpc-linux no longer generates
> bdnz for:
> ...
A patch for this testcase:
http://gcc.gnu.org/ml/gcc-patches/2008-11/msg0
--- Comment #23 from rakdver at gcc dot gnu dot org 2008-11-20 08:06
---
Subject: Bug 32283
Author: rakdver
Date: Thu Nov 20 08:05:12 2008
New Revision: 142035
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142035
Log:
PR rtl-optimization/32283
* tree-
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot
|dot org
--- Comment #58 from rakdver at gcc dot gnu dot org 2008-12-10 22:55
---
(In reply to comment #56)
> Re. comment #52:
>
> I've pasted the test case in the audit trail here as plain text -- it's pretty
> small and it shows the problem nicely. The issue is
--- Comment #65 from rakdver at gcc dot gnu dot org 2008-12-12 20:34
---
Subject: Bug 32044
Author: rakdver
Date: Fri Dec 12 20:32:47 2008
New Revision: 142719
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142719
Log:
PR tree-optimization/32044
* tre
--- Comment #66 from rakdver at gcc dot gnu dot org 2008-12-12 20:42
---
(In reply to comment #64)
> I agree that the most practical short-term solution is to avoid transforming
> the loop into a division.
>
> However, I'm also interested in what we think the right l
--- Comment #6 from rakdver at gcc dot gnu dot org 2009-01-21 16:41 ---
(In reply to comment #4)
> Zdenek, could you please comment on comment #3?
>
Adding MTP_AFTER_MOVE seems like the right thing to do; after all, even the
comments for may_trap_or_fault_p specify that it
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot
|dot org
--- Comment #6 from rakdver at gcc dot gnu dot org 2009-05-15 00:34 ---
(In reply to comment #5)
> It is number of iteration analysis that gets it wrong (I suppose it might get
> confused by the two exits of the loop?).
Sort of; # of iterations analysis assumes that pointers neve
--- Comment #9 from rakdver at gcc dot gnu dot org 2009-05-20 00:34 ---
Subject: Bug 40087
Author: rakdver
Date: Wed May 20 00:33:54 2009
New Revision: 147727
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147727
Log:
PR tree-optimization/40087
* tree-
--- Comment #12 from rakdver at gcc dot gnu dot org 2009-05-22 20:43
---
Subject: Bug 40087
Author: rakdver
Date: Fri May 22 20:43:39 2009
New Revision: 147806
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147806
Log:
PR tree-optimization/40087
* tree-
--- Comment #2 from rakdver at gcc dot gnu dot org 2009-05-26 17:50 ---
(In reply to comment #1)
> It looks more like the code in GCC 4.3 is wrong and should use lhs here.
> Zdenek?
simple_iv should return the same result in both cases, so it should not really
matter. Is ther
--- Comment #5 from rakdver at gcc dot gnu dot org 2009-06-20 17:08 ---
(In reply to comment #4)
> With MAX_DOMINATORS_TO_WALK zero and find_loop_niter_by_eval completely
> disabled
> (checking enabled compiler, built with -O0):
>
> tree iv optimization : 11.12 ( 6%)
--- Comment #3 from rakdver at gcc dot gnu dot org 2009-08-07 08:44 ---
(In reply to comment #1)
> The tree optimizers canonicalize the loop to
>
> :
> # i_5 = PHI
> # ivtmp.23_1 = PHI
> f2 ();
> i_3 = i_5 + 1;
> ivtmp.23_4 = ivtmp.23_1 - 1;
--- Comment #20 from rakdver at gcc dot gnu dot org 2005-11-04 10:04
---
Patch:
http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00246.html
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rakdver at gcc dot gnu dot org 2005-11-04 10:35 ---
There are two reasons we do not produce the code as in the comment #1:
1) This would require reversing the loop, which is currently implemented in
mainline only in old loop optimizer, in a very weak fashion. More
--- Comment #4 from rakdver at gcc dot gnu dot org 2005-11-04 13:39 ---
Nevertheless, the fact that boolean_true_node has overflow flag set is wrong,
this should not happen -- shared constants should not be modified.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24599
--- Comment #5 from rakdver at gcc dot gnu dot org 2005-11-04 14:02 ---
This happens in c-typeck.c:build_c_cast:
value = convert (type, value);
/* Ignore any integer overflow caused by the cast. */
if (TREE_CODE (value) == INTEGER_CST)
{
/* If
--- Comment #5 from rakdver at gcc dot gnu dot org 2005-11-09 22:30 ---
I am testing the following patch:
Index: except.c
===
*** except.c(revision 106702)
--- except.c(working copy
--- Comment #6 from rakdver at gcc dot gnu dot org 2005-11-09 22:36 ---
Yes, this is indeed the case. I am testing the fix.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24760
--- Comment #23 from rakdver at gcc dot gnu dot org 2005-11-11 13:38
---
Subject: Bug 22509
Author: rakdver
Date: Fri Nov 11 13:38:07 2005
New Revision: 106783
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106783
Log:
PR rtl-optimization/22509
* local
--- Comment #3 from rakdver at gcc dot gnu dot org 2005-11-13 10:02 ---
This is easy to implement; the question is whether we really want to waste
compile time to handle this type of examples that do not seem very likely to
appear in practice.
--
http://gcc.gnu.org/bugzilla
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot
|dot org
--- Comment #5 from rakdver at gcc dot gnu dot org 2005-11-14 09:16 ---
The testcase comes from gcc testsuite.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23821
--- Comment #15 from rakdver at gcc dot gnu dot org 2005-11-15 14:27
---
Subject: Bug 24762
Author: rakdver
Date: Tue Nov 15 14:27:48 2005
New Revision: 107017
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107017
Log:
PR rtl-optimization/24762
*
--- Comment #5 from rakdver at gcc dot gnu dot org 2005-11-16 12:13 ---
A patch is here (only the ivopts and get_tmr_operands parts). I am retesting
it now.
http://gcc.gnu.org/ml/gcc-patches/2005-08/msg01608.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24793
--- Comment #6 from rakdver at gcc dot gnu dot org 2005-11-17 12:33 ---
Patch:
http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01283.html
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #34 from rakdver at gcc dot gnu dot org 2005-11-17 13:35
---
It behaves somewhat erratically on SPEC2000 (it increases the overall score,
but there are some significant regressions). And, it also causes us to produce
worse code for this testcase at the moment, due to a
--- Comment #35 from rakdver at gcc dot gnu dot org 2005-11-17 15:09
---
Created an attachment (id=10263)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10263&action=view)
Patch
After some playing with fold, I arrived to the following patch, that almost
works. With th
1 - 100 of 610 matches
Mail list logo
