--- 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 #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 #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), intent(in) :: b(:)
integer a1
--- 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
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 triplet: i386-linux
http://gcc.gnu.org
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
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
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
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 dot gnu dot org
http
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 #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=gccview=revrev=140685
Log:
PR tree-optimization/37574
* tree-vectorizer.c
--
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 #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 alignment
--- 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=gccview=revrev=139224
Log:
PR bootstrap/37152
* tree-vect-transform.c
--- 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 == may have
been intended
--- Comment #2 from dorit at gcc dot gnu dot org 2008-07-22 10:39 ---
(In reply to comment #1)
One problem is vectorizable_conversion. Is there a way to support
V4DF/V4DI - D4SI/V4SF
V8SI - V8SF
With the current framework, the only way to support
V8SI - V8SF
is to implement
--- 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 -fno-tree-vectorize
--- 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 #6 from dorit at gcc dot gnu dot org 2008-01-03 10:08 ---
(In reply to comment #5)
I can confirm that pulseaudio 0.9.8 sources which caused the crash, compile
fine now with the latest gcc 4.3 snapshot.
thanks. (I usually prefer to wait for the person who reported the bug
--- Comment #7 from dorit at gcc dot gnu dot org 2008-01-03 10:17 ---
fixed
--
dorit at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from dorit at gcc dot gnu dot org 2007-12-27 19:14 ---
Subject: Bug 34591
Author: dorit
Date: Thu Dec 27 19:14:17 2007
New Revision: 131206
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131206
Log:
PR tree-optimization/34591
* tree-vect-trasnform.c
--
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-12-19 09:38 ---
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 it?)
--
http://gcc.gnu.org
--- Comment #5 from dorit at gcc dot gnu dot org 2007-12-17 11:14 ---
Subject: Bug 34445
Author: dorit
Date: Mon Dec 17 11:13:56 2007
New Revision: 131006
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131006
Log:
PR tree-optimization/34445
* tree-vect-trasnform.c
--- Comment #4 from dorit at gcc dot gnu dot org 2007-12-16 13:06 ---
testing this patch:
*** tree-vect-transform.c (revision 130987)
--- tree-vect-transform.c (working copy)
*** vect_estimate_min_profitable_iters (loop
*** 197,214
factor = 1
--
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 #14 from dorit at gcc dot gnu dot org 2007-11-22 15:22 ---
closed, given recent feedback
--
dorit at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from dorit at gcc dot gnu dot org 2007-11-22 15:17 ---
(In reply to comment #12)
...
Richard, is this related to the issue you reported in
http://gcc.gnu.org/ml/gcc-patches/2007-10/msg01127.html
(looks like the same error)?
...
Yes, these are likely similar
--- Comment #14 from dorit at gcc dot gnu dot org 2007-11-22 15:14 ---
(In reply to comment #13)
Dorit, can you please take a look again?
I will not be able to look into this in the next couple of weeks, sorry.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33869
--- Comment #7 from dorit at gcc dot gnu dot org 2007-11-13 13:29 ---
fixed
--
dorit at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from dorit at gcc dot gnu dot org 2007-11-07 18:06 ---
(In reply to comment #0)
Following testcase exposes optimization problem with current SVN gcc:
...
the same address
is accessed with unaligned access (3) as well as aligned access.
This is a missed-optimization
--- Comment #3 from dorit at gcc dot gnu dot org 2007-11-06 18:11 ---
I don't think these are related to PR33680. Sounds like we may be generating a
stmt with a cond_expr at the rhs. The data-reference analysis results in:
base_address: blocks
offset from base address
--- Comment #4 from dorit at gcc dot gnu dot org 2007-11-06 18:29 ---
We probably need to call the gimplifier (if we don't already) and also apply
Zdenek's patch that allows gimplifying rhs cond_exprs -
http://gcc.gnu.org/ml/gcc-patches/2007-07/msg02052.html.
Yep - I just tried
--- Comment #3 from dorit at gcc dot gnu dot org 2007-11-04 03:49 ---
Subject: Bug 33987
Author: dorit
Date: Sun Nov 4 03:48:58 2007
New Revision: 129880
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129880
Log:
PR tree-optimization/33987
* tree-vect-transform.c
--- Comment #11 from dorit at gcc dot gnu dot org 2007-11-04 04:09 ---
(In reply to comment #10)
Doesn't fail on trunk since r129797:
2007-10-31 Sebastian Pop [EMAIL PROTECTED]
PR tree-optimization/32377
...
before:
pr27549.C:58: note: create runtime check for data
--
dorit at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #2 from dorit at gcc dot gnu dot org 2007-11-03 04:06 ---
testing this fix:
Index: tree-vect-transform.c
===
*** tree-vect-transform.c (revision 129763)
--- tree-vect-transform.c (working copy
--- Comment #3 from dorit at gcc dot gnu dot org 2007-10-31 17:46 ---
(In reply to comment #2)
Works for me. Try a newer 4.2.x release.
I wonder if the fix for PR25413 fixed this problem - it went into 4.2 on July
25th, just shortly after 4.2.1 was released :-( but should be in 4.2.2
--- Comment #6 from dorit at gcc dot gnu dot org 2007-11-01 00:55 ---
thanks!
but the problem is that in the vectorizer, DR_STEP has to be an
INTEGER_CST: for instance,
step = TREE_INT_CST_LOW (DR_STEP (dra));
...
|| tree_int_cst_compare (DR_STEP (dra), DR_STEP (drb
--- Comment #17 from dorit at gcc dot gnu dot org 2007-10-30 05:25 ---
Subject: Bug 32893
Author: dorit
Date: Tue Oct 30 05:25:10 2007
New Revision: 129764
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129764
Log:
PR tree-optimization/32893
* tree-vectorize.c
--- Comment #5 from dorit at gcc dot gnu dot org 2007-10-23 19:50 ---
Subject: Bug 33860
Author: dorit
Date: Tue Oct 23 19:50:18 2007
New Revision: 129587
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129587
Log:
PR tree-optimization/33860
* tree-vect-transform.c
--- Comment #4 from dorit at gcc dot gnu dot org 2007-10-22 22:54 ---
There's some bad interaction here between the data-interleaving support and the
outer-loop support - these are not yet supported together, however it still
slipped through the checks during the analysis phase
--- Comment #7 from dorit at gcc dot gnu dot org 2007-10-23 03:24 ---
Subject: Bug 33834
Author: dorit
Date: Tue Oct 23 03:24:06 2007
New Revision: 129571
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129571
Log:
PR tree-optimization/33834
PR tree-optimization
--- Comment #5 from dorit at gcc dot gnu dot org 2007-10-23 03:24 ---
Subject: Bug 33835
Author: dorit
Date: Tue Oct 23 03:24:06 2007
New Revision: 129571
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129571
Log:
PR tree-optimization/33834
PR tree-optimization
--- 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-analyze.c
--- 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 #6 from dorit at gcc dot gnu dot org 2007-10-22 04:28 ---
I'm testing this patch. It fixes the two testcases, while allowing the first
testcase to get vectorized. (the last bit in the patch is the fix for PR33835):
Index: tree-vect-analyze.c
--- Comment #4 from dorit at gcc dot gnu dot org 2007-10-22 04:37 ---
I'm testing a patch that would fix both this PR and PR33834 (posted it under
the PR33834 entry). By the way, this testcase does not get vectorized with
current mainline (an Oct21 snapshot) because the call to cos
--- 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 #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 #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 and seamonkey-1.1.3-6.fc8
--- 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/msg00327.html
--- 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 *s, int w)
{
int
--- 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=gccview=revrev=128415
Log:
PR tree-optimization/33373
* tree-vect-analyze
--- 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-analyze.c
--- 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=gccview=revrev=128265
Log:
PR tree-optimization/33301
* tree-vect-analyze
--- 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 vectorizer:
I can't get
--- 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=gccview=revrev=128242
Log:
PR tree-optimization/33299
* tree-vect-transform.c
: 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 #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 phi-nodes
--
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
to an invariant type-
promotion in the loop
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: dorit at gcc dot gnu dot org
ReportedBy: dorit
--- 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 copy
--- 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
--- 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 invariant in that loop, so the whole
--- 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 references
--- 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
sink
does it. When I use
--- 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 before
--- 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:
SUBROUTINE
--- 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
However, I am going to submit
-optimization
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
-optimization
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
--- 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:
...
Compiler options used
--- 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 |Added
--
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 #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()
accessed an unaligned memory.
since
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 triplet: powerpc64-linux
--- 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 :: i,j
do
--- 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 testing
- e.g
--- 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) , iznum, ix, iy
--- 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 related
--- 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
--- 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 #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 all.
I see
--- 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 open
--- 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=gccview=revrev=126904
Log:
2007-07-25 Dorit Nuzman [EMAIL PROTECTED]
Devang
--- 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-patches/2007-07
--- 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 no longer segfault.
I'd
--- 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=gccview=revrev=126868
Log:
2007-07-23 Dorit Nuzman [EMAIL PROTECTED]
merge
--- 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 committed to mainline.
Ryan
--- 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 fact
1 - 100 of 144 matches
Mail list logo
