--- Comment #14 from rakdver at gcc dot gnu dot org 2010-08-30 19:50
---
Subject: Bug 45427
Author: rakdver
Date: Mon Aug 30 19:50:05 2010
New Revision: 163659
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163659
Log:
PR tree-optimization/45427
* tree-ssa-loop
--- Comment #10 from rakdver at gcc dot gnu dot org 2010-08-28 10:37
---
Created an attachment (id=21582)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21582action=view)
proposed patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45427
--- Comment #11 from rakdver at gcc dot gnu dot org 2010-08-28 10:38
---
Does the patch fix your problem?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45427
--- Comment #13 from rakdver at gcc dot gnu dot org 2010-08-28 13:39
---
Created an attachment (id=21584)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21584action=view)
a new version of the patch
There were some problems with the previous patch (that could only manifest for
some
--- Comment #7 from rakdver at gcc dot gnu dot org 2010-07-26 14:47 ---
By the time the code reaches ivopts, it looks (modulo SSA form) this way:
signed char x = -128, tmp;
for (;;)
{
tmp = -x;
foo ((int) x, (int) tmp, x==-128);
...
if (x == 127)
break;
x
--- Comment #16 from rakdver at gcc dot gnu dot org 2010-06-25 09:04
---
Now, in the first loop if we decide to unswitch on cond3, it transforms this
into:
...
If cond3 tests some variable that is initialized only if cond1 is false, this
unswitching (besides not being very useful
--- Comment #17 from rakdver at gcc dot gnu dot org 2010-06-25 09:12
---
(In reply to comment #16)
Now, in the first loop if we decide to unswitch on cond3, it transforms this
into:
...
If cond3 tests some variable that is initialized only if cond1 is false
--- Comment #8 from rakdver at gcc dot gnu dot org 2010-01-30 12:01 ---
(In reply to comment #7)
Oh, and Zdenek might have an idea about the condition simplification in
unswitching.
I agree that some of the checks in tree_unswitch_single_loop are badly placed
-- it does not make
--
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 2010-01-16 12:53
---
/* Reject a tailcall if the type conversion might need
285 additional code. */
286if (gimple_assign_cast_p (stmt)
287 TYPE_MODE (TREE_TYPE (dest
--- 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
bb 3:
# i_5 = PHI i_3(4), 0(2)
# ivtmp.23_1 = PHI ivtmp.23_4(4), 10(2)
f2 ();
i_3 = i_5 + 1;
ivtmp.23_4 = ivtmp.23_1 - 1
--- 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%) usr 0.07 ( 5%) sys
--- 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 there some
--- 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=gccview=revrev=147806
Log:
PR tree-optimization/40087
* tree-ssa-loop
--- 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=gccview=revrev=147727
Log:
PR tree-optimization/40087
* tree-ssa-loop
--- 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 never 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 #5 from rakdver at gcc dot gnu dot org 2009-04-26 18:37 ---
(In reply to comment #4)
void foo(int *);
void f2(int dst[3], int R)
{
int i, inter[2];
for (i = 1; i R; i++) {
inter[0] = 1;
inter[1] = 1;
}
foo(inter);
}
Warns at -Os or also at -O2
--- Comment #3 from rakdver at gcc dot gnu dot org 2009-04-25 22:44 ---
I cannot reproduce this in 4.5; all the unnecessary loads are removed.
The fix is to avoid the load part of load-store-motion of course.
I've considered this, but it seems much easier to just let the unnecessary
--
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 #10 from rakdver at gcc dot gnu dot org 2009-02-25 19:09
---
The difference between
D.1254 = a[0] + ((long unsigned int) ((unsigned int) len + 4294967295) + 1)
* 2;
(original) and
D.1255 = ((long unsigned int) a + 2) + (long unsigned int) ((unsigned int
--- Comment #19 from rakdver at gcc dot gnu dot org 2009-02-18 00:50
---
Smaller testcase:
void bar();
void foo(int i1)
{
int i;
for (i=0; i=i1; ++i)
bar();
}
What the # of iterations analysis does is the following:
-- the number of iterations is i1, unless i1
--- Comment #18 from rakdver at gcc dot gnu dot org 2009-02-12 19:58
---
It works once you change the loop exit condition to i i1. Same effects
with unsigned variables (adjust the lower bound to sth like 2 to avoid ill
effects).
There is nothing to fix if unsigned variables
--
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-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 should behave
--- 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=gccview=revrev=142719
Log:
PR tree-optimization/32044
* tree-scalar
--- 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 long-term solution
--
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 that with -Os, on all
targets
--- 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=gccview=revrev=142035
Log:
PR rtl-optimization/32283
* tree-ssa-loop
--- 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/msg00792.html
--- 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=gccview=revrev=141911
Log:
PR tree-optimization/37950
* tree-flow
--- 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-10 18:32 ---
It might be that only number_of_iterations_lt_to_ne needs to be changed,
I looked at other uses of fold_build* in tree-ssa-loop-niter.c and quite
some others also look at least fishy (at least those generating
--
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 #26 from rakdver at gcc dot gnu dot org 2008-08-06 21:51
---
Created an attachment (id=16036)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16036action=view)
possible fix
One place where this can be fixed is fwprop (something like the attached
patch). I am not sure
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
CC||bonzini at gnu dot org
AssignedTo|rakdver at gcc dot gnu dot
--- Comment #27 from rakdver at gcc dot gnu dot org 2008-08-06 21:56
---
(In reply to comment #26)
Created an attachment (id=16036)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16036action=view) [edit]
possible fix
One place where this can be fixed is fwprop (something like
--- Comment #4 from rakdver at gcc dot gnu dot org 2008-07-25 07:56 ---
(In reply to comment #3)
(In reply to comment #2)
Also IV-opts is messing up anyways, it should have done out+1 as the base
instead of out, blah.
Filed as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36905
--- Comment #2 from rakdver at gcc dot gnu dot org 2008-03-31 14:20 ---
Subject: Bug 35729
Author: rakdver
Date: Mon Mar 31 14:19:52 2008
New Revision: 133755
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133755
Log:
PR rtl-optimization/35729
* 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 #5 from rakdver at gcc dot gnu dot org 2008-02-15 02:59 ---
forwprop3 changes
SR.40_22 = D.2672_11(ab)-D.2242;
# D.2672_315(ab) = PHI D.2672_11(ab)(14), D.2672_11(ab)(19),
D.2672_11(ab)(17)
SR.40_27 = SR.40_22;
D.2705_29 = SR.40_27-D.2120;
(where the life ranges of D_11
--
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 2008-01-27 15:35 ---
The patch fixes the problem for me on ppc (tested in crosscompiler) and on
amd64, I did not check the other architectures (arm, hppa, mips)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34711
--- Comment #3 from rakdver at gcc dot gnu dot org 2008-01-26 22:45 ---
Subject: Bug 34711
Author: rakdver
Date: Sat Jan 26 22:44:19 2008
New Revision: 131877
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131877
Log:
PR target/34711
* tree-ssa-loop-ivopts.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 #5 from rakdver at gcc dot gnu dot org 2008-01-21 16:43 ---
I cannot reproduce this with the current mainline (rev 131696), neither with
the original testcase nor the reduced one.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34590
--- Comment #7 from rakdver at gcc dot gnu dot org 2008-01-21 17:25 ---
I get that ICE as well; but that is a dup of 34330 (and seems to be different
from the problem described in this PR).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34590
--- Comment #5 from rakdver at gcc dot gnu dot org 2008-01-21 17:35 ---
(In reply to comment #3)
This is a vectorizer vs not being able to run may_alias after it
can you please remind me why we can't run may_alias after the vectorizer? (and
what do you think can be done about
--
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 #48 from rakdver at gcc dot gnu dot org 2008-01-12 03:59
---
(In reply to comment #47)
Most of the PRE/FRE memory is spent in copied VOPs VECs. Unfortunately we
cannot move them to heap memory easily as the get shared in the PRE tables...
I tried to be explicit
--- Comment #8 from rakdver at gcc dot gnu dot org 2008-01-03 21:23 ---
(In reply to comment #7)
The final tree IL looks good, so I suspect the RTL loop optimizer gets this
wrong.
add r1, sp, #56 // upper loop-bound; should have been #12
I actually wanted to say 'should
--- Comment #15 from rakdver at gcc dot gnu dot org 2008-01-03 22:22
---
(In reply to comment #14)
Fixed.
The fix looks a bit ugly. tree-data-ref should probably use double_ints or
mpz, instead (although this cleanup is obviously for 4.4).
--
http://gcc.gnu.org/bugzilla
--- Comment #2 from rakdver at gcc dot gnu dot org 2007-12-19 15:01 ---
Subject: Bug 34355
Author: rakdver
Date: Wed Dec 19 15:01:19 2007
New Revision: 131063
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131063
Log:
PR tree-optimization/34355
* tree-parloops.c
--- Comment #2 from rakdver at gcc dot gnu dot org 2007-12-18 18:51 ---
I do not see a way how to fix this in 4.3, other than disabling vectorizer when
parallelization is enabled, or vice versa.
--
rakdver at gcc dot gnu dot org changed:
What|Removed
--
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 #17 from rakdver at gcc dot gnu dot org 2007-12-16 20:29
---
A possible way how to solve the problem:
http://gcc.gnu.org/ml/gcc-patches/2007-12/msg00769.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32283
--
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 2007-11-30 00:32
---
Subject: Bug 34244
Author: rakdver
Date: Fri Nov 30 00:32:04 2007
New Revision: 130527
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130527
Log:
PR tree-optimization/34244
* tree-vrp.c
--- Comment #9 from rakdver at gcc dot gnu dot org 2007-11-29 04:29 ---
Patch: http://gcc.gnu.org/ml/gcc-patches/2007-11/msg01607.html
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rakdver at gcc dot gnu dot org 2007-11-27 13:57 ---
I will have a look. What target is this on, and what flags are used for
compilation?
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rakdver at gcc dot gnu dot org 2007-11-27 16:48 ---
as it may be zero, in case offset_46 is = 0.
Sebastian, Zdenek - any idea what goes wrong here?
# of iteration analysis records an assumption that offset_46 = 0. However,
this is simplified to true
--- Comment #5 from rakdver at gcc dot gnu dot org 2007-11-27 17:00 ---
# of iteration analysis records an assumption that offset_46 = 0. However,
this is simplified to true, as the value range of offset_46 is set to [0,0] by
vrp (which seems to be wrong); so the problem is probably
--- Comment #25 from rakdver at gcc dot gnu dot org 2007-11-26 00:48
---
Created an attachment (id=14637)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14637action=view)
Patch to make ivopts take autoincrement addressing modes into account
Ivopts take autoincrement addressing
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|rakdver at gcc dot gnu dot |unassigned at gcc dot gnu
|org
--- Comment #30 from rakdver at gcc dot gnu dot org 2007-11-26 05:08
---
The patch improves size of adler32 (and several other files in zlib) by about
2%. However, overall on the whole csibe it is neutral (the sum of the sizes of
all the files increases by 0.02%) -- the changes
--- Comment #20 from rakdver at gcc dot gnu dot org 2007-11-24 19:08
---
Couldn't ivopts be taught to recognize dec and branch on zero patterns
k_114 = k_15 + -1;
if (k_114 != 0)
goto bb 10;
else
goto bb 11;
and take into account their breakage for its cost
--- Comment #23 from rakdver at gcc dot gnu dot org 2007-11-24 21:56
---
Let me have a look what's going on here.
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #24 from rakdver at gcc dot gnu dot org 2007-11-24 22:28
---
(In reply to comment #20)
Couldn't ivopts be taught to recognize dec and branch on zero patterns
k_114 = k_15 + -1;
if (k_114 != 0)
goto bb 10;
else
goto bb 11;
and take
--- Comment #6 from rakdver at gcc dot gnu dot org 2007-11-16 02:38 ---
(In reply to comment #2)
Is there be any way to modify the code such that GCC would have an easier time
seeing this? I tried using 'assert(rnd_to_2 % 2 == 0)' (since glibc's
__assert_fail is marked with noreturn
--- Comment #4 from rakdver at gcc dot gnu dot org 2007-11-13 17:34 ---
(In reply to comment #3)
Either we should use correct order of arguments in chrec_evaluate (that
function
is swapping CHREC_LEFT based expression with CHREC_RIGHT based expression
for pointer_plus addition
--- Comment #3 from rakdver at gcc dot gnu dot org 2007-10-31 17:39 ---
It does not reproduce for me on i686-linux, either. Do you pass any special
flags to configure?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33915
--- Comment #1 from rakdver at gcc dot gnu dot org 2007-10-30 03:32 ---
I cannot reproduce it (using ./configure --enable-languages=c --target=m32c-elf
on amd64-linux). Does it still fail for you?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33915
--- Comment #7 from rakdver at gcc dot gnu dot org 2007-10-17 16:07 ---
(In reply to comment #0)
I'm getting the following ICE with gcc 4.2.0 RC3. It compiles fine
with gcc 4.1 and 4.3 20070515.
(sid)23889:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/g++ -c -O2
freehdl
--- Comment #34 from rakdver at gcc dot gnu dot org 2007-10-13 20:40
---
Does this still reproduce for you? After workarounding the crtstuff.c
misscompilation as described in
http://gcc.gnu.org/ml/gcc-patches/2007-10/msg00743.html, bootstrap with
BOOT_CFLAGS=-O2 -ftree-vectorize
--- Comment #4 from rakdver at gcc dot gnu dot org 2007-10-12 22:27 ---
Subject: Bug 33714
Author: rakdver
Date: Fri Oct 12 22:26:47 2007
New Revision: 129277
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129277
Log:
PR tree-optimization/33714
* tree-ssa-loop
--- Comment #3 from rakdver at gcc dot gnu dot org 2007-10-12 03:03 ---
(In reply to comment #2)
Confirmed. You need HWI of 32bits to trigger the problem. Maybe latent on
the trunk (I didn't check if it fails there, too).
The problem was fixed in mainline in this commit (I somehow
--
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 #15 from rakdver at gcc dot gnu dot org 2007-09-20 18:47
---
I see. I thought we might be able to recognize the overflow in computing
the final value of val and as val is signed, not use that for the exit
test. Or simply give up in computing the final value for val
--- Comment #6 from rakdver at gcc dot gnu dot org 2007-09-19 16:45 ---
Mine.
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo
--- Comment #8 from rakdver at gcc dot gnu dot org 2007-09-19 16:56 ---
t #2)
Technically the testcase invokes undefined behavior because 'val' overflows
during loop execution. Practically from a QOI point of view the undefinedness
should not propagate to the loop exit test (though
--- Comment #21 from rakdver at gcc dot gnu dot org 2007-09-17 15:39
---
Subject: Bug 26449
Author: rakdver
Date: Mon Sep 17 15:38:48 2007
New Revision: 128549
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128549
Log:
PR rtl-optimization/26449
* loop-invariant.c
--- Comment #20 from rakdver at gcc dot gnu dot org 2007-09-14 15:57
---
(In reply to comment #19)
Zdenek, the fix in Comment #5 is wrong (please look at Comment #11 why), as
cofirmed by a couple of dupes. From PR 33428:
actually the fix in loop-invariant is correct for the original
--- Comment #33 from rakdver at gcc dot gnu dot org 2007-09-12 14:49
---
Zdenek, I think you had a patch to make lim more precise in this regard?
Yes. Revital Eres was trying to put it into shape suitable for mainline a few
months ago, I am not sure what is the status
--- Comment #11 from rakdver at gcc dot gnu dot org 2007-09-08 13:19
---
Subject: Bug 32283
Author: rakdver
Date: Sat Sep 8 13:18:49 2007
New Revision: 128272
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128272
Log:
PR tree-optimization/32283
* tree-ssa-loop
--- Comment #10 from rakdver at gcc dot gnu dot org 2007-09-06 17:57
---
I'm testing a patch.
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rakdver at gcc dot gnu dot org 2007-09-05 12:51 ---
(In reply to comment #4)
Ah, I only found add_noreturn_fake_exit_edges which obviously didn't help.
connect_infinite_loops_to_exit does. Thx.
dominance.c contains code (probably buggy) that adds such edges
--- Comment #12 from rakdver at gcc dot gnu dot org 2007-08-31 15:34
---
Subject: Bug 33224
Author: rakdver
Date: Fri Aug 31 15:34:45 2007
New Revision: 127996
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127996
Log:
PR rtl-optimization/33224
* loop-iv.c
--- Comment #10 from rakdver at gcc dot gnu dot org 2007-08-30 20:05
---
I know how to fix the problem, now.
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rakdver at gcc dot gnu dot org 2007-08-22 23:05 ---
Subject: Bug 32949
Author: rakdver
Date: Wed Aug 22 23:05:05 2007
New Revision: 127720
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127720
Log:
2007-08-22 Zdenek Dvorak [EMAIL PROTECTED]
PR tree
--- Comment #1 from rakdver at gcc dot gnu dot org 2007-08-21 21:29 ---
This patch fixes the problem:
Index: tree-ssa-loop-niter.c
===
*** tree-ssa-loop-niter.c (revision 127674)
--- tree-ssa-loop-niter.c
--- Comment #1 from rakdver at gcc dot gnu dot org 2007-08-19 20:08 ---
(In reply to comment #0)
In the following testcase:
subroutine sub(aa,bb,n,m)
implicit none
integer, intent(in) :: n,m
real, intent(inout) :: aa(n,m)
real, intent(in):: bb(n,m)
integer :: i,j
--- Comment #30 from rakdver at gcc dot gnu dot org 2007-08-13 18:06
---
(In reply to comment #28)
Subject: Re: Bootstrap with vectorization enabled fails with ICE on PPC
Most everyone else bootstraps GCC on PPC64 with
--with-cpu=default32. Are you missing some packages
--- Comment #2 from rakdver at gcc dot gnu dot org 2007-07-29 15:14 ---
I would be curious to hear from
Zdenek: is there something that could be done in the loop optimizer dealing
generally with this common patterns?
Not at the moment. It would be possible to implement
--- Comment #6 from rakdver at gcc dot gnu dot org 2007-07-26 12:09 ---
rs6000_conditional_register_usage ();
memset (reg_class_size, 0, 84);
gets compiled to
vxorv0,v0,v0
...
bl 0x104f0c68 rs6000_conditional_register_usage
...
stvxv0,r0,r9
addir9,r11,32
stw r0,80
--- Comment #2 from rakdver at gcc dot gnu dot org 2007-07-16 09:56 ---
(In reply to comment #1)
Zdenek, I think this change also breaks FDO compiles with tramp3d, sed, gawk
and gzip (the resulting -fprofile-use binaries segfault).
At least now we know why the check
--- Comment #5 from rakdver at gcc dot gnu dot org 2007-07-16 19:39 ---
Patch: http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01462.html
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from rakdver at gcc dot gnu dot org 2007-07-17 03:56 ---
Subject: Bug 32773
Author: rakdver
Date: Tue Jul 17 03:56:40 2007
New Revision: 126700
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126700
Log:
PR rtl-optimization/32773
* cfglayout.c
--- Comment #5 from rakdver at gcc dot gnu dot org 2007-07-12 07:36 ---
Patch: http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01130.html
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
1 - 100 of 607 matches
Mail list logo
