--
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-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-
--- 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 #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
--
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 #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
--- 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 #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 #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 #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 #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 #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 #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 #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 #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
--
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
--
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 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
--- 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 #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 #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 #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 #14 from rakdver at gcc dot gnu dot org 2006-04-07 13:20
---
(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(int *ie, int *je, double *x)
> {
> int i, j;
>
zation
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rakdver at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27039
--- Comment #8 from rakdver at gcc dot gnu dot org 2006-04-03 16:52 ---
(In reply to comment #6)
> I believe c-common.c:pointer_int_sum is wrong in relying on pointer overflow
> during conversion of the integer offset to an unsigned pointer. I'm sending
> a patch that
--- Comment #29 from rakdver at gcc dot gnu dot org 2006-04-03 16:31
---
(In reply to comment #27)
> With a bit simplified testcase (my computer does not have enough memory for
> this one), we spend 30% of compile time in rewrite_update_phi_arguments.
> However, only 1.6% (le
--- Comment #27 from rakdver at gcc dot gnu dot org 2006-04-03 14:16
---
With a bit simplified testcase (my computer does not have enough memory for
this one), we spend 30% of compile time in rewrite_update_phi_arguments.
However, only 1.6% (less then 1% of compile time) of the
--- Comment #10 from rakdver at gcc dot gnu dot org 2006-04-02 16:04
---
(In reply to comment #7)
> Subject: Re: Number of iterations not know for simple loop
>
> > > I thought if we know that we are looking at the loop header copy
> > > condition that
>
--- Comment #8 from rakdver at gcc dot gnu dot org 2006-03-29 01:41 ---
Subject: Bug 25985
Author: rakdver
Date: Wed Mar 29 01:41:27 2006
New Revision: 112484
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112484
Log:
PR tree-optimization/25985
* tree-
--- Comment #12 from rakdver at gcc dot gnu dot org 2006-03-29 01:34
---
Subject: Bug 26643
Author: rakdver
Date: Wed Mar 29 01:34:51 2006
New Revision: 112483
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112483
Log:
PR tree-optimization/26643
* tree-
--- Comment #4 from rakdver at gcc dot gnu dot org 2006-03-29 01:03 ---
(In reply to comment #1)
> Note that we in principle know the number of iterations - just we cannot prove
> the loop runs at least once in number of iterations analysis. Of course we
> know this because we
--- Comment #4 from rakdver at gcc dot gnu dot org 2006-03-28 12:08 ---
With this testcase, problem reproduces both in 4.1 and in mainline:
int try (int *a)
{
return a + -1 > a;
}
int main(void)
{
int bla[100];
if (try (bla + 50))
abort ();
return 0;
}
--
h
--- Comment #3 from rakdver at gcc dot gnu dot org 2006-03-27 22:33 ---
(gdb) call debug_generic_stmt (ret)
startD.1278_2 + -3B > startD.1278_2 + 396B;
(gdb) call debug_generic_stmt (fold (ret))
1
I guess the reasoning of fold is: it is pointer arithmetics, so it
does not wrap. (
--
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 #12 from rakdver at gcc dot gnu dot org 2006-03-21 21:35
---
(In reply to comment #11)
> This is definitely a bug in loop-iv.c -- once biv_p (SET_DEST (single_set
> (insn))) returns true, iv_analyze_result must succeed as well.
While I still consider this desirable,
--- Comment #3 from rakdver at gcc dot gnu dot org 2006-03-16 18:51 ---
More precisely, the correct chrec would be
(int) (char) {0,+,1}
since we assume signed chrecs do not overflow.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26719
--- Comment #2 from rakdver at gcc dot gnu dot org 2006-03-16 18:50 ---
This is a scev analysis problem; on code
D.2160_17 = (signed char) j_15;
D.2161_18 = (int) D.2160_17;
it says D.2161_18 = {0, +, 1}; however, since it wraps at 128 to -127, this is
not correct -- (int) {0
--- Comment #7 from rakdver at gcc dot gnu dot org 2006-03-16 14:29 ---
Patch:
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01019.html
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from rakdver at gcc dot gnu dot org 2006-03-16 03:15 ---
Actually, my previous comment is wrong, it is ivcanon (more precisely, # of
iterations analysis). Consider this testcase:
#include
void bla(int x)
{
if (x < -100)
exit (0);
}
int main(void)
{
int b
--- Comment #5 from rakdver at gcc dot gnu dot org 2006-03-16 02:49 ---
"Added canonical iv..." seems correct to me (at least, -fno-tree-loop-ivcanon
does not fix the problem). However, -fno-tree-loop-ivcanon -fno-ivopts fixes
it, so it is mine anyway.
--
http://g
--
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 #11 from rakdver at gcc dot gnu dot org 2006-03-15 13:21
---
Patch:
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00925.html
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from rakdver at gcc dot gnu dot org 2006-03-14 01:10
---
>From reading loop-unroll.c, I believe that we could safely have
>analyze_iv_to_split_insn return NULL instead of aborting when
>iv_analyze_result returns false.
>However, I wouldn't want to m
--
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 #10 from rakdver at gcc dot gnu dot org 2006-03-14 01:01
---
The following patch should fix the problem. I am fairly sure a similar check
used to be somewhere in ivopts, but it probably got lost when MEM_REFs were
introduced (I am somewhat surprised ivopts do not ICE and
--
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 #8 from rakdver at gcc dot gnu dot org 2006-03-13 12:28 ---
Subject: Bug 26254
Author: rakdver
Date: Mon Mar 13 12:28:09 2006
New Revision: 111998
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111998
Log:
PR rtl-optimization/26254
* loop-inv
--- Comment #4 from rakdver at gcc dot gnu dot org 2006-03-01 12:10 ---
Created an attachment (id=10944)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10944&action=view)
Possible patch
(In reply to comment #2)
> Working on it.
>
are you still working on this
--- Comment #20 from rakdver at gcc dot gnu dot org 2006-02-28 14:24
---
Subject: Bug 25632
Author: rakdver
Date: Tue Feb 28 14:24:05 2006
New Revision: 111565
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111565
Log:
PR c++/25632
* init.c (constant
--- Comment #14 from rakdver at gcc dot gnu dot org 2006-02-24 15:20
---
Ivopts fail to use the complex addressing mode, thus forcing one more biv into
inner loop. Since this makes it impossible to allocate registers for the loop,
we get another penalty for spilling.
Changing the
--- Comment #14 from rakdver at gcc dot gnu dot org 2006-02-23 21:03
---
Subject: Bug 26316
Author: rakdver
Date: Thu Feb 23 21:03:05 2006
New Revision: 111397
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111397
Log:
PR rtl-optimization/26316
* r
--- Comment #9 from rakdver at gcc dot gnu dot org 2006-02-17 19:54 ---
SFT for D.2477.a is SFT.12. Before vectorizer is run, SFT.12 has is_alias_tag
== false and may_aliases = {TMT.32}; thus, we would only add a vuse for TMT.32
to the statement, and this is subsumed by the VDEF
--- Comment #13 from rakdver at gcc dot gnu dot org 2006-02-17 18:38
---
Patch:
http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01461.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 #8 from rakdver at gcc dot gnu dot org 2006-02-16 17:53 ---
This seems somewhat more complicated than I thought -- vectorizer actually does
not touch the statement with changed vops, it just clobbers alias info somehow
so that we are adding vops for it we did not before. I
--- Comment #5 from rakdver at gcc dot gnu dot org 2006-02-16 15:47 ---
Subject: Bug 26296
Author: rakdver
Date: Thu Feb 16 15:47:20 2006
New Revision: 39
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=39
Log:
PR rtl-optimization/26296
* Mak
--- Comment #15 from rakdver at gcc dot gnu dot org 2006-02-16 15:25
---
Now fixed also in 4.1.
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from rakdver at gcc dot gnu dot org 2006-02-16 15:23
---
Subject: Bug 26209
Author: rakdver
Date: Thu Feb 16 15:23:24 2006
New Revision: 38
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=38
Log:
PR tree-optimization/26209
*
--- Comment #9 from rakdver at gcc dot gnu dot org 2006-02-16 13:53 ---
Given that do_tablejump was the very first setter of MEM_NOTRAP_P, it is not
likely that it would be the wrong one (unless all other setters that came later
chose the other possible semantics).
--
http
--- Comment #6 from rakdver at gcc dot gnu dot org 2006-02-16 13:38 ---
Sadly, Jakub is probably right -- since the very beginning, MEM_NOTRAP_P was
used to mean that the mem cannot trap in its current context. This makes
MEM_NOTRAP_P completely useless as far as code motion is
--- Comment #7 from rakdver at gcc dot gnu dot org 2006-02-16 12:52 ---
No, that patch does not fix the problem. It is however the same type of
problem -- vectorizer not updating virtual operands properly (I had tried to
find all places in vectorizer where this could happen in that
--- Comment #11 from rakdver at gcc dot gnu dot org 2006-02-14 23:55
---
Subject: Bug 26209
Author: rakdver
Date: Tue Feb 14 23:55:22 2006
New Revision: 110999
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110999
Log:
PR tree-optimization/26209
*
--- Comment #2 from rakdver at gcc dot gnu dot org 2006-02-14 00:51 ---
Without further information (use of pc) loop-invariant has no way how to know
that this insn cannot be moved; so I think your patch should be correct.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26272
--- Comment #10 from rakdver at gcc dot gnu dot org 2006-02-13 23:19
---
Subject: Bug 26235
Author: rakdver
Date: Mon Feb 13 23:19:49 2006
New Revision: 110939
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110939
Log:
PR rtl-optimization/26235
--- Comment #3 from rakdver at gcc dot gnu dot org 2006-02-13 20:27 ---
Subject: Bug 26247
Author: rakdver
Date: Mon Feb 13 20:27:44 2006
New Revision: 110924
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110924
Log:
PR rtl-optimization/26247
--- Comment #3 from rakdver at gcc dot gnu dot org 2006-02-13 20:27 ---
Subject: Bug 26248
Author: rakdver
Date: Mon Feb 13 20:27:44 2006
New Revision: 110924
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110924
Log:
PR rtl-optimization/26247
--- Comment #5 from rakdver at gcc dot gnu dot org 2006-02-13 19:53 ---
I have submited my patch, as it is useful regardless of whether the new hook
will be added or not. I am not sure whether it is reasonable to introduce a
new target hook just to handle this special case; if you
--- Comment #4 from rakdver at gcc dot gnu dot org 2006-02-13 13:59 ---
Created an attachment (id=10835)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10835&action=view)
Other possible patch
This might be a safer choice; although it would be nice to get all conditions
righ
--
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 #8 from rakdver at gcc dot gnu dot org 2006-02-13 11:21 ---
Subject: Bug 26222
Author: rakdver
Date: Mon Feb 13 11:21:23 2006
New Revision: 110912
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110912
Log:
PR rtl-optimization/26222
* fu
--- Comment #2 from rakdver at gcc dot gnu dot org 2006-02-13 01:34 ---
The patch for PR26247 should fix this one as well.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26248
--- Comment #1 from rakdver at gcc dot gnu dot org 2006-02-13 01:32 ---
This should fix the problem:
Index: loop-invariant.c
===
*** loop-invariant.c(revision 110898)
--- loop-invariant.c(working copy
--- Comment #5 from rakdver at gcc dot gnu dot org 2006-02-13 00:02 ---
Subject: Bug 26225
Author: rakdver
Date: Mon Feb 13 00:02:37 2006
New Revision: 110898
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110898
Log:
PR rtl-optimization/26225
* loop-inv
--- Comment #3 from rakdver at gcc dot gnu dot org 2006-02-12 23:17 ---
Just for sure -- does not the patch for PR 26235 fix this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26244
--- Comment #8 from rakdver at gcc dot gnu dot org 2006-02-12 22:32 ---
Subject: Bug 26232
Author: rakdver
Date: Sun Feb 12 22:32:33 2006
New Revision: 110897
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110897
Log:
PR rtl-optimization/26232
* loop-inv
--- Comment #9 from rakdver at gcc dot gnu dot org 2006-02-12 21:12 ---
This should fix the problem (could you please verify it?). I am really
surprised this problem did not show on other architectures.
Index: loop-invariant.c
--
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 2006-02-12 20:35 ---
At the moment, I would like to get things working as fast and as safely as
possible; the improvements like the one you propose may be considered later.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26232
--- Comment #5 from rakdver at gcc dot gnu dot org 2006-02-12 19:24 ---
Probably related to
http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00446.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26197
--- Comment #1 from rakdver at gcc dot gnu dot org 2006-02-12 19:17 ---
Can you please add preprocessed source for the testcase (minimized,
preferably)?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26235
--- Comment #4 from rakdver at gcc dot gnu dot org 2006-02-12 17:36 ---
Could you please test the following patch?
Index: loop-invariant.c
===
*** loop-invariant.c(revision 110850)
--- loop-invariant.c(working copy
--- Comment #3 from rakdver at gcc dot gnu dot org 2006-02-12 17:08 ---
The test for cc0 should probably be in may_assign_reg_p or in
find_invariant_insn, not in move_invariant_reg.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26232
--
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-02-11 18:23 ---
Could you please check whether the following patch fixes the problem?
I am not sure whether I would be able to build ada crosscompiler.
Index: loop-invariant.c
--- Comment #7 from rakdver at gcc dot gnu dot org 2006-02-11 18:16 ---
Created an attachment (id=10823)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10823&action=view)
Possible fix
I am testing the attached patch that seems to fix the problem (although I am
not real
--- Comment #7 from rakdver at gcc dot gnu dot org 2006-02-09 23:52 ---
There is no simple way how scev could determine that x == i at the end of loop
(unless we insert something like ASSERT_EXPRs at the condition). Persuading
dom and VRP not to perform this transformation would
--- Comment #20 from rakdver at gcc dot gnu dot org 2006-02-09 22:34
---
Fixed.
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #19 from rakdver at gcc dot gnu dot org 2006-02-09 22:34
---
Subject: Bug 24762
Author: rakdver
Date: Thu Feb 9 22:34:23 2006
New Revision: 110815
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110815
Log:
PR rtl-optimization/24762
* d
--- Comment #6 from rakdver at gcc dot gnu dot org 2006-02-05 15:29 ---
Fixed.
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from rakdver at gcc dot gnu dot org 2006-02-05 14:58 ---
Subject: Bug 26087
Author: rakdver
Date: Sun Feb 5 14:58:07 2006
New Revision: 110614
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110614
Log:
PR rtl-optimization/26087
* r
--- Comment #4 from rakdver at gcc dot gnu dot org 2006-02-04 21:30 ---
Patch:
http://gcc.gnu.org/ml/gcc-patches/2006-02/msg00333.html
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rakdver at gcc dot gnu dot org 2006-02-03 14:14 ---
The things are a bit more complicated -- get_condition would be correct,
but in cfglayout mode, some labels and jumps are omitted, and the order of
blocks is arbitrary.
--
http://gcc.gnu.org/bugzilla
--- Comment #2 from rakdver at gcc dot gnu dot org 2006-02-03 13:57 ---
The code looks like
(insn 86 85 77 2 (set (reg:CC 127)
(compare:CC (reg/v:SI 125 [ ei1 ])
(const_int 0 [0x0]))) -1 (nil)
(nil))
(note 77 86 18 2 NOTE_INSN_LOOP_BEG)
...
a lot of insns
--- Comment #21 from rakdver at gcc dot gnu dot org 2006-02-02 17:57
---
I have posted the patch, let's see what the reactions will be.
http://gcc.gnu.org/ml/gcc-patches/2006-02/msg00146.html
--
rakdver at gcc dot gnu dot org changed:
What|Re
--- Comment #15 from rakdver at gcc dot gnu dot org 2006-01-26 23:52
---
The patch fixes the problem by making gimplification of cleanups much more
robust, and able to handle nested statements, at the expense of producing a bit
worse code.
--
http://gcc.gnu.org/bugzilla
--- Comment #14 from rakdver at gcc dot gnu dot org 2006-01-26 23:51
---
Created an attachment (id=10738)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10738&action=view)
Possible patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24996
--- Comment #13 from rakdver at gcc dot gnu dot org 2006-01-23 08:53
---
One more question; how is the throw code supposed to work?
We allocate D.2069, initialize it, if there is a problem
during it initialization, we deallocate it, then
pass it to __cxa_throw anyway? This does not
--- Comment #11 from rakdver at gcc dot gnu dot org 2006-01-22 21:49
---
This ICE works this way: to build_throw, we get expression exp that looks like
TARGET_EXPR
Where t1 and t2 are TARGET_EXPRs with cleanups (*). build_throw generates code
TARGET_EXPR ;
try
{
*(struct
301 - 400 of 610 matches
Mail list logo
