--- 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=gcc&view=rev&rev=163659
Log:
PR tree-optimization/45427
* tree-
--- 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=21584&action=view)
a new version of the patch
There were some problems with the previous patch (that could only manif
--- 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 #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=21582&action=view)
proposed patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45427
--- 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 #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 cond
--- 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 no
--- 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 no
--- 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 (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 #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 #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 #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 #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 #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 #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
--
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;
> }
>
>
--- 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 unn
--
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 in
--
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 #22 from rakdver at gcc dot gnu dot org 2009-02-18 04:47
---
(In reply to comment #21)
> Subject: Re: loop number of iterations analysis not working
>
> > If the program terminates before i would wrap, then the number of
> > iterations was not MAXINT
--- 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:
--- 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
--
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
--- 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 #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 #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
--
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 #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-
--- 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 #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 #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 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 #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=16036&action=view) [edit]
> possible fix
>
> One place where this can be fixed i
--
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 #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=16036&action=view)
possible fix
One place where this can be fixed is fwprop (something like the attached
patch). I am n
--- 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/bug
--- 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=gcc&view=rev&rev=133755
Log:
PR rtl-optimization/35729
* loop-inv
--
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
SR.40_27 = SR.40_22;
D.2705_29 = &SR.40_27->D.2120;
(where the life ranges of D_11 and D_315 do not overlap)
to
SR.40_2
--
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=gcc&view=rev&rev=131877
Log:
PR target/34711
* tree-ssa-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
--- 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 thi
--- 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 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
--
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 ex
--- 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/bugzi
--- 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 actuall
--- 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=gcc&view=rev&rev=131063
Log:
PR tree-optimization/34355
* tree-pa
--
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 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
--- 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=gcc&view=rev&rev=130527
Log:
PR tree-optimization/34244
* tr
--- 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 #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 th
--- 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 simplif
--- 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 #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 in
--
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 #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=14637&action=view)
Patch to make ivopts take autoincrement addressing modes into account
Ivopts take autoincrement add
--- 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
--- 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 |
--- 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 ;
> else
> goto ;
>
> and tak
--- 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
> __as
--- 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_p
--- 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++
--- 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-vect
--- 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=gcc&view=rev&rev=129277
Log:
PR tree-optimization/33714
* tree-
--- 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 thi
--
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 valu
--- 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
--- 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 #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=gcc&view=rev&rev=128549
Log:
PR rtl-optimization/26449
--- 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 f
--- 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 of t
--- 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=gcc&view=rev&rev=128272
Log:
PR tree-optimization/32283
* tree-
--- 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 |
--- 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
--- 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=gcc&view=rev&rev=127996
Log:
PR rtl-optimization/33224
* l
--- 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=gcc&view=rev&rev=127720
Log:
2007-08-22 Zdenek Dvorak <[EMAIL PROTECTED]&g
--- 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):
--- 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
--- 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 imple
--- Comment #6 from rakdver at gcc dot gnu dot org 2007-07-26 12:09 ---
rs6000_conditional_register_usage ();
memset (®_class_size, 0, 84);
gets compiled to
vxorv0,v0,v0
...
bl 0x104f0c68
...
stvxv0,r0,r9
addir9,r11,32
stw r0,80(r11)
stvxv0,r0,r11
addir11
--- 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=gcc&view=rev&rev=126700
Log:
PR rtl-optimization/32773
* cfg
--- 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 #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 was
1 - 100 of 610 matches
Mail list logo
