--- Comment #9 from dorit at gcc dot gnu dot org 2009-01-27 12:40 ---
(In reply to comment #4)
> The testcase should be
> subroutine to_product_of(self,a,b,a1,a2)
> complex(kind=8) :: self (:)
> complex(kind=8), intent(in) :: a(:,:)
> complex(kind=8),
--- Comment #7 from dorit at gcc dot gnu dot org 2009-01-27 12:46 ---
related testcase/PR: PR37021
and related discussion: http://gcc.gnu.org/ml/gcc-patches/2009-01/msg01322.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33113
--- Comment #11 from dorit at gcc dot gnu dot org 2005-12-18 08:46 ---
Subject: Bug 24378
Author: dorit
Date: Sun Dec 18 08:46:30 2005
New Revision: 108746
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108746
Log:
PR tree-optimization/24378
* t
--- Comment #12 from dorit at gcc dot gnu dot org 2005-12-18 11:20 ---
Subject: Bug 24378
Author: dorit
Date: Sun Dec 18 11:20:17 2005
New Revision: 108750
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108750
Log:
PR tree-optimization/24378
* t
--- Comment #21 from dorit at gcc dot gnu dot org 2006-08-03 20:35 ---
Subject: Bug 27770
Author: dorit
Date: Thu Aug 3 20:35:05 2006
New Revision: 115910
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115910
Log:
PR tree-optimization/27770
* tree-vect
--- Comment #19 from dorit at gcc dot gnu dot org 2006-08-10 12:07 ---
Subject: Bug 26197
Author: dorit
Date: Thu Aug 10 12:07:22 2006
New Revision: 116060
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116060
Log:
PR tree-optimization/26197
* tree-ssa
--- Comment #12 from dorit at gcc dot gnu dot org 2007-02-12 13:15 ---
Subject: Bug 29145
Author: dorit
Date: Mon Feb 12 13:14:52 2007
New Revision: 121844
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121844
Log:
PR tree-optimization/29145
* tree-da
--- Comment #6 from dorit at gcc dot gnu dot org 2007-02-14 14:11 ---
Subject: Bug 30771
Author: dorit
Date: Wed Feb 14 14:10:57 2007
New Revision: 121950
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121950
Log:
PR tree-optimization/30771
* t
--- Comment #10 from dorit at gcc dot gnu dot org 2007-02-22 08:16 ---
Subject: Bug 30858
Author: dorit
Date: Thu Feb 22 08:16:18 2007
New Revision: 10
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=10
Log:
PR tree-optimization/30858
* tree-vect
--- Comment #6 from dorit at gcc dot gnu dot org 2007-03-17 14:43 ---
Subject: Bug 31041
Author: dorit
Date: Sat Mar 17 14:43:30 2007
New Revision: 123023
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123023
Log:
PR tree-optimization/31041
* t
--- Comment #9 from dorit at gcc dot gnu dot org 2007-03-25 13:08 ---
Subject: Bug 30784
Author: dorit
Date: Sun Mar 25 12:08:29 2007
New Revision: 123197
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123197
Log:
PR tree-optimization/30784
* fold
--- Comment #3 from dorit at gcc dot gnu dot org 2007-07-15 18:31 ---
> With loop distribution we could vectorize these loops using peeling to handle
> misaligned stores (multiple stores make peeling for alignment insufficient
> here).
wonder what the loop-distribution pa
--- Comment #5 from dorit at gcc dot gnu dot org 2007-07-15 19:02 ---
(In reply to comment #4)
> The arrays in this example all have compatible alignment. This is one of the
> advantages many compilers see in the use of the "old-fashioned" block COMMON.
> In the us
--- Comment #11 from dorit at gcc dot gnu dot org 2007-07-16 08:02 ---
(In reply to comment #10)
> any chance of a 4.2 backport?
sure (as soon as 4.2 gets out of freeze. unfortunately we missed the 4.2.1
release).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25413
--- Comment #1 from dorit at gcc dot gnu dot org 2007-07-19 18:09 ---
I think this is similar to PR19347?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32824
--- Comment #1 from dorit at gcc dot gnu dot org 2007-07-19 18:15 ---
...
> Though the last add is extra and does not need to be done, we can get rid of
> it
> by having vect_var_.36 being set initially to {e, 0, 0, 0} .
The problem is that often initializing a vector to {e
--- Comment #3 from dorit at gcc dot gnu dot org 2007-07-19 18:28 ---
ah, I misunderstood you - when you wrote before that you manually LIM'd e I
assumed it was because LIM didn't work. I see that the problem is with the
"garbage" that LIM leaves behind:
pr32824.c:
--- Comment #8 from dorit at gcc dot gnu dot org 2007-07-24 07:50 ---
Subject: Bug 31776
Author: dorit
Date: Tue Jul 24 07:50:10 2007
New Revision: 126868
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126868
Log:
2007-07-23 Dorit Nuzman <[EMAIL PROTECTED]>
--- Comment #4 from dorit at gcc dot gnu dot org 2007-07-24 08:50 ---
> i'm wondering if this could be related to a problem we're seeing with
> segfaults
> caused by misaligned movdqa instructions in zlib compiled with
> -ftree-vectorize.
A fix for PR25413 was
--- Comment #5 from dorit at gcc dot gnu dot org 2007-07-24 08:53 ---
(In reply to comment #4)
> I just tried to reproduce this bug on IA64 Linux (and HP-UX) with ToT sources
> (version 126242) and was not able to. Can anyone else reproduce this with ToT
> sources?
does the
--- Comment #4 from dorit at gcc dot gnu dot org 2007-07-24 08:59 ---
Just for the record - as we discussed last week, there are two ways to solve
this problem - either have LIM leave behind it cleaner code (smthing like
copy-prop + dce to eliminate the extra copy stmts), or improve the
--- Comment #13 from dorit at gcc dot gnu dot org 2007-07-24 09:05 ---
David, can you confirm that this PR can now be closed?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25413
--- Comment #3 from dorit at gcc dot gnu dot org 2007-07-24 13:05 ---
(In reply to comment #1)
> ... We actually had both options in the vectorizer for a while
> (guarded by ADJUST_IN_EPILOG hard-coded #define), however we didn't know how
> to
> choose between the
--- Comment #17 from dorit at gcc dot gnu dot org 2007-07-25 08:40 ---
This looks like an unrelated problem - the vectorizer does not perform loop
peeling here so it's not an issue of natural alignment. Lets open a separate PR
for this one, unless there's already one op
--- Comment #18 from dorit at gcc dot gnu dot org 2007-07-25 08:51 ---
Subject: Bug 25413
Author: dorit
Date: Wed Jul 25 08:51:12 2007
New Revision: 126904
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126904
Log:
2007-07-25 Dorit Nuzman <[EMAI
--- Comment #19 from dorit at gcc dot gnu dot org 2007-07-25 08:52 ---
problem fixed.
--
dorit at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #21 from dorit at gcc dot gnu dot org 2007-07-25 11:11 ---
> Of course after my patch for PR 16660, the patch here should be
> changed to just return true always.
In this case, Ryan, could you please also try to see if Andrew's patch
(http://gcc.gnu.org/ml/gcc-p
--- Comment #1 from dorit at gcc dot gnu dot org 2007-07-25 20:43 ---
thanks a lot for checking both patches!
> With this patch zlib appears to compile successfully. The loop is
> vectorized with an "alignment of access forced using peeling" note and linked
> apps
--- Comment #8 from dorit at gcc dot gnu dot org 2007-07-28 19:20 ---
> v0 (and v10 are scratch registers and not saved.
so does it look like a register allocation bug then?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32582
--- Comment #3 from dorit at gcc dot gnu dot org 2007-07-28 21:03 ---
(In reply to comment #2)
> > Andrew, makes sense to you?
> I think my patch only checks PREFERRED_STACK_BOUNDARY and not STACK_BOUNDARY
> which is why it does not work but I have not looked into it at
--- Comment #24 from dorit at gcc dot gnu dot org 2007-08-01 10:08 ---
> I do; however, I got stuck with another bootstrap problem at the moment
> (vectorization changes alignment of variables, which causes a
> misscompilation of crtend.o on my machine;
I wonder if this is r
--- Comment #5 from dorit at gcc dot gnu dot org 2007-08-01 11:57 ---
Ryan, I wonder what happens if you force alignment in the source code, like so:
unsigned short count[MAXBITS+1] __attribute__ ((__aligned__(16))) ;
In this case the vectorizer does not change the alignment of
--- Comment #4 from dorit at gcc dot gnu dot org 2007-08-01 11:36 ---
Also just for the record - the testcase for this PR is here:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25413#c14
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32893
--- Comment #9 from dorit at gcc dot gnu dot org 2007-08-14 20:17 ---
PR32824 discusses a similar issue.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25621
--- Comment #5 from dorit at gcc dot gnu dot org 2007-08-14 20:47 ---
Additional testcases:
(1) see loop in lines 23 and 32 in
http://gcc.gnu.org/ml/gcc-help/2007-08/msg00171.html
(2)
> SUBROUTINE SUSCEP(L,Iz)
> IMPLICIT NONE
> INTEGER L , Iz(L,L) , iznu
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dorit at gcc dot gnu dot org
GCC build triplet: powerpc64-linux
GCC host triplet: powerpc64-linux
GCC target trip
--- Comment #6 from dorit at gcc dot gnu dot org 2007-08-19 13:47 ---
> Sebastian - any thughts/plans?
Here's another 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 ::
--- Comment #2 from dorit at gcc dot gnu dot org 2007-08-20 05:55 ---
> Making us return symbolic stride would not be hard. The problem is that data
> dependence analysis would fail anyway,
sometimes (not in this testcases) there won't be a need for dependence testi
--- Comment #10 from dorit at gcc dot gnu dot org 2007-08-26 07:49 ---
(In reply to comment #9)
> I've confirmed that the problem is caused by '-ftree-vectorize' passed to
> compile gcc. More precisely, a 'movdqa' instruction in constraint_operands()
zation
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dorit at gcc dot gnu dot org
GCC build triplet: powerpc64-linux
GCC host triplet: powerpc64-linux
GCC target triplet: powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33222
zation
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dorit at gcc dot gnu dot org
GCC build triplet: powerpc64-linux
GCC host triplet: powerpc64-linux
GCC target triplet: powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33224
--- Comment #1 from dorit at gcc dot gnu dot org 2007-08-29 09:04 ---
> In the testcase below, after the inner-loop gets completely unrolled, the
> enclosing i-loop does not get unrolled because of failure to analyze the loop
> iv, possibly due to a bug in df:
...
> Comp
--- Comment #1 from dorit at gcc dot gnu dot org 2007-08-29 09:08 ---
I accidentally entered this bug twice. I'm closing this one, and will use
PR33224 instead.
--
dorit at gcc dot gnu dot org changed:
What|Removed |
--
dorit at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dorit at gcc dot gnu dot org
|dot org
--- Comment #3 from dorit at gcc dot gnu dot org 2007-08-30 08:12 ---
(In reply to comment #2)
> I suspect this might be due to not updating the rd information after
> unrolling.
> Can you check if
> analyze_insns_in_loop() (which calls df_analyze()) is being called just
--- Comment #2 from dorit at gcc dot gnu dot org 2007-08-30 10:12 ---
> There are two time consuming routines in air.f90 of the Polyhedron
> benchmark that are not vectorized: lines 1328 and 1354. These appear
> in the top counting of execution time with oprofile:
>
>
--- Comment #5 from dorit at gcc dot gnu dot org 2007-08-30 16:29 ---
> dorit,
> i am having trouble exactly reproducing this example because you did not
> give the svn revision and so all of the numbers are a little bit
> different.
it's revision 127623
> Ho
--- Comment #1 from dorit at gcc dot gnu dot org 2007-08-31 13:39 ---
(In reply to comment #0)
> The innermost loop in "j" cannot be vectorized because of the
> irregular code in that loop, i.e. the condition "IF ( l.NE.k )". But
> the cond expression is i
--- Comment #3 from dorit at gcc dot gnu dot org 2007-08-31 13:57 ---
...
> This is due to data ref analysis problems:
> ./fatigue.f90:14: note: not vectorized: data ref analysis failed
> (*stress_tensor.0_16)[D.1508_168] = D.1513_173
> ./fatigue.f90:14: note: bad data refer
--- Comment #3 from dorit at gcc dot gnu dot org 2007-08-31 14:18 ---
(In reply to comment #2)
> Subject: Re: Missed opportunities for vectorization due to invariant
> condition
> > Looks like -fno-tree-pre is not enough, because if PRE doesn't do it, then
> >
--- Comment #2 from dorit at gcc dot gnu dot org 2007-09-04 11:44 ---
(In reply to comment #1)
> Confirmed. It looks like the vectorizer forgets to update the PHI node for
> stmp_var:
yes. I suspect I didn't expect at the time that there would be two
loop-closed-ssa-form p
--
dorit at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dorit at gcc dot gnu dot org
|dot org
fprintf (vect_dump, "get vectype for scalar type: ");
--
Summary: wrong vectorization factor due to an invariant type-
promotion in the loop
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity
--- Comment #3 from dorit at gcc dot gnu dot org 2007-09-04 19:11 ---
I'm testing this patch:
Index: tree-vect-transform.c
===
*** tree-vect-transform.c (revision 128037)
--- tree-vect-transform.c (working
--- Comment #4 from dorit at gcc dot gnu dot org 2007-09-04 19:14 ---
(by the way, fast-math should not be required here, but that's a different
bug... will fix that soonish)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33299
l
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dorit at gcc dot gnu dot org
GCC build triplet: powerpc-linux
GCC host triplet: powerpc-linux
GCC target triplet: powerpc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33319
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dorit at gcc dot gnu dot org
GCC build triplet: i386-linux
GCC host triplet: i386-linux
GCC target triplet: i386-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33320
--- Comment #5 from dorit at gcc dot gnu dot org 2007-09-07 15:00 ---
Subject: Bug 33299
Author: dorit
Date: Fri Sep 7 15:00:11 2007
New Revision: 128242
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128242
Log:
PR tree-optimization/33299
* t
--- Comment #1 from dorit at gcc dot gnu dot org 2007-09-08 09:19 ---
Subject: Bug 33301
Author: dorit
Date: Sat Sep 8 09:19:39 2007
New Revision: 128265
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128265
Log:
PR tree-optimization/33301
* tree-vect
--- Comment #2 from dorit at gcc dot gnu dot org 2007-09-08 09:23 ---
fix committed
--
dorit at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #6 from dorit at gcc dot gnu dot org 2007-09-08 09:24 ---
fix committed
--
dorit at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #2 from dorit at gcc dot gnu dot org 2007-09-08 09:42 ---
(In reply to comment #1)
> (In reply to comment #0)
> > When the testcase gcc.dg/tree-ssa/predcom-3.c is compiled with
> > vectorization it
> > ICes when the dataref analysis called from vectoriz
--- Comment #2 from dorit at gcc dot gnu dot org 2007-09-10 09:08 ---
Testing this patch (it's a bug in the fix for PR33301. I accidentally treated
TYPE_SIZE_UNIT as a constant, whereas it's really a tree...):
Index: tree-vect
--- Comment #3 from dorit at gcc dot gnu dot org 2007-09-12 07:10 ---
Subject: Bug 33373
Author: dorit
Date: Wed Sep 12 07:09:38 2007
New Revision: 128415
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128415
Log:
PR tree-optimization/33373
* tree-vect
--- Comment #7 from dorit at gcc dot gnu dot org 2007-09-14 18:49 ---
(In reply to comment #6)
> I can bootstrap current trunk (r128479) with -ftree-vectorize on
> x86_64-unknown-linux-gnu for some time now, and, according to
> http://gcc.gnu.org/ml/gcc-patches/2007-09/msg0
--- Comment #5 from dorit at gcc dot gnu dot org 2007-09-14 20:53 ---
(In reply to comment #4)
> Very similar testcase with the difference that it is not fixed by r128415 and
> makes current trunk segfault in VEC_tree_base_pop():
> void f (unsigned int *d, unsigned int
--- Comment #7 from dorit at gcc dot gnu dot org 2007-09-19 14:28 ---
(In reply to comment #6)
> It looks like
> zlib compiled w/ -O -msse -ftree-vectorize (built with fedora's rpm package
> gcc-4.1.2-17)
> has same problem.
> In my environment, rpm-4.4.2.1-7.fc8 a
--- Comment #16 from dorit at gcc dot gnu dot org 2007-10-03 18:52 ---
Ryan, thanks a lot for the info. FYI, I started a discussion about this here:
http://gcc.gnu.org/ml/gcc-patches/2007-10/msg00202.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32893
--- Comment #35 from dorit at gcc dot gnu dot org 2007-10-15 05:52 ---
bootstrap with vectorization enabled with your patch applied passes for me on
ppc64-linux. thanks!!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32582
--- Comment #4 from dorit at gcc dot gnu dot org 2007-10-21 06:39 ---
I was able to reproduce this on i386-linux.
Looks like it's related to PLUS_EXPR vs. POINTER_PLUS_EXPR. The folowing patch
fixes this testcase:
Index: tree-vect-anal
--- Comment #5 from dorit at gcc dot gnu dot org 2007-10-21 07:14 ---
This patch fixes it:
Index: tree-vect-transform.c
===
*** tree-vect-transform.c (revision 129521)
--- tree-vect-transform.c (working copy
--- Comment #3 from dorit at gcc dot gnu dot org 2007-10-21 08:07 ---
The proposed fix/work-around for PR33834 also happens to fix this PR. But the
real problem is that we try to access a NULL argument (operand 2 of a CALL_EXPR
may be NULL). So we should probably at least add something
--- Comment #1 from dorit at gcc dot gnu dot org 2008-08-18 20:11 ---
(In reply to comment #0)
> I just tried to compile GNU CC version 4.4 snapshot 20080815 with the
> Intel C compiler and it said
> gcc/tree-vect-transform.c(2488): warning #187: use of "=" where &
--- Comment #2 from dorit at gcc dot gnu dot org 2008-08-19 07:15 ---
Subject: Bug 37152
Author: dorit
Date: Tue Aug 19 07:14:26 2008
New Revision: 139224
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139224
Log:
PR bootstrap/37152
* tree-vect-tra
--- Comment #3 from dorit at gcc dot gnu dot org 2008-08-22 13:31 ---
(In reply to comment #2)
> The x86_64 generated code looks like
...
> I wonder why we do not use movups instead.
> t.i:3: note: Alignment of access forced using peeling.
> t.i:3: note: Peeling for align
--
dorit at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dorit at gcc dot gnu dot org
|dot org
--- Comment #3 from dorit at gcc dot gnu dot org 2008-09-21 13:18 ---
happens during outer-loop vectorization. I'm looking into it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37574
--- Comment #4 from dorit at gcc dot gnu dot org 2008-09-26 06:29 ---
Subject: Bug 37574
Author: dorit
Date: Fri Sep 26 06:28:01 2008
New Revision: 140685
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140685
Log:
PR tree-optimization/37574
* tree-vect
unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dorit at gcc dot gnu dot org
GCC build triplet: i386-linux
GCC host triplet: i386-linux
GCC target
D
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dorit at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37693
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dorit at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37694
l array read
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dorit at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37695
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dorit at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37698
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dorit at gcc do
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dorit at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37700
--- Comment #19 from dorit at gcc dot gnu dot org 2008-01-28 13:20 ---
> Fixed?
In a way, yes. The problem is avoided by generating too conservative code.
AFAIU, a better solution may be expected in 4.4 from the stack alignment
branch. In any case this segfault PR can be closed,
--- Comment #1 from dorit at gcc dot gnu dot org 2008-02-25 10:21 ---
(In reply to comment #0)
> It is beneficial to unroll reduction loop (and split the reduction target) to
> reduce dependence height due to recurrence, but GCC does not perform such
> optimization (-O3
--- Comment #2 from dorit at gcc dot gnu dot org 2009-02-01 21:06 ---
(reminds me of a couple missed-optimization PRs where vectorization is also
failing due to casts - PR31873 , PR26128 - don't know if this is related)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39068
--- Comment #5 from dorit at gcc dot gnu dot org 2009-03-08 14:25 ---
This is a known problem... Indeed when Zdenek introduced predictive-commoning
there was a discussion on whether to schedule it before or after vectorization.
AFAIR, it ended up getting scheduled before the vectorizer
--- Comment #7 from dorit at gcc dot gnu dot org 2007-05-01 07:59 ---
Subject: Bug 31589
Author: dorit
Date: Tue May 1 07:58:59 2007
New Revision: 124315
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124315
Log:
PR testsuite/31589
* gcc.dg/vect/vec
--- Comment #7 from dorit at gcc dot gnu dot org 2007-05-03 13:55 ---
Subject: Bug 31699
Author: dorit
Date: Thu May 3 12:54:45 2007
New Revision: 124375
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124375
Log:
PR tree-optimization/31699
* tree-vect-a
--- Comment #5 from dorit at gcc dot gnu dot org 2007-06-08 08:58 ---
Subject: Bug 32224
Author: dorit
Date: Fri Jun 8 08:57:54 2007
New Revision: 125566
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125566
Log:
PR tree-optimization/32224
* tree-vect-a
--- Comment #5 from dorit at gcc dot gnu dot org 2007-06-14 09:39 ---
Subject: Bug 32274
Author: dorit
Date: Thu Jun 14 09:39:31 2007
New Revision: 125703
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125703
Log:
PR target/32274
* gcc.dg/vect/pr3222
--- Comment #13 from dorit at gcc dot gnu dot org 2007-07-01 08:32 ---
Fix committed, PR can be closed.
--
dorit at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from dorit at gcc dot gnu dot org 2007-07-01 08:35 ---
A fix was committed, looks like the patch can be closed.
--
dorit at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from dorit at gcc dot gnu dot org 2007-07-01 08:38 ---
This fix was committed with the wrong PR number (sorry about that):
2007-02-19 Dorit Nuzman <[EMAIL PROTECTED]>
PR tree-optimization/30975
* tree-vect-trasnform.c (vect_get_vec_def_for_stm
--- Comment #2 from dorit at gcc dot gnu dot org 2007-07-01 08:42 ---
(oops - wrong keyword)
--
dorit at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from dorit at gcc dot gnu dot org 2007-07-01 08:47 ---
I was able to reproduce the behavior on a Pentinum4 with a recent 4.3 snapshot.
It doesn't look like it's the vectorizer's fault - nothing gets vectorized.
However, if I disable the tree-level if-conve
--- Comment #7 from dorit at gcc dot gnu dot org 2007-07-01 08:51 ---
PR31966 is also wrong code which seems to be a result of the tree-level
if-conversion (nothing gets vectorized these, and if tree-if-conversion is
disabled everything works ok).
--
http://gcc.gnu.org/bugzilla
--- Comment #4 from dorit at gcc dot gnu dot org 2007-07-01 08:52 ---
This may be related to PR32533 (also wrong-code due to tree-if-conversion).
--
dorit at gcc dot gnu dot org changed:
What|Removed |Added
1 - 100 of 144 matches
Mail list logo
