--- Comment #3 from dorit at il dot ibm dot com 2005-12-05 11:11 ---
> Dorit, the 3 loops are now vectorized because of versioning despite the target
> being vect_no_align. Can we adjust the dg commands?
yes, that's exactly what the patch I sent in Comment #1 does.
I
--- Comment #3 from dorit at il dot ibm dot com 2005-12-05 14:17 ---
> Dorit, is it only a matter of changing the expected error message?
Yes - the error message checks that the vectorizer detected that it's not worth
while to vectorize the loop because all operations in the
--- Comment #5 from dorit at il dot ibm dot com 2005-12-07 16:35 ---
> What's the best approach to fixing this? Punting in vectorizable_reduction
> if we know beforehand that the loop will be versioned?
> /* Same if the loop is to be versioned. */
> if
--- Comment #7 from dorit at il dot ibm dot com 2005-12-07 20:49 ---
(In reply to comment #6)
Can you test the attached patch?
Unfortunrately it's relative to autovect-branch, but hopefully it would easily
apply to mainline/4.1. Unbootstrapped, hardly tested...
Index: tree
--- Comment #9 from dorit at il dot ibm dot com 2005-12-14 15:38 ---
Thanks for testing the patch. I finally submitted it:
http://gcc.gnu.org/ml/gcc-patches/2005-12/msg01071.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24378
--- Comment #2 from dorit at il dot ibm dot com 2005-12-15 12:41 ---
The problem is that the vectorizer applies loop-peeling in order to align the
data reference *(m->c+i), and peeling only works correctly if the data is
naturally aligned (aligned on it's type size). This is
--- Comment #3 from dorit at il dot ibm dot com 2005-12-15 12:50 ---
related discussion: http://gcc.gnu.org/ml/gcc/2005-12/msg00390.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25413
--- Comment #6 from dorit at il dot ibm dot com 2006-01-04 07:33 ---
Maybe related to:
2005-12-26 Kazu Hirata <[EMAIL PROTECTED]>
PR tree-optimization/25125
* convert.c (convert_to_integer): Don't narrow the type of a
PLUX_EXPR or MINUS_EXPR if
--- Comment #7 from dorit at il dot ibm dot com 2006-01-04 07:36 ---
(sorry, didn't notice it was already diagnosed as such)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25590
--- Comment #10 from dorit at il dot ibm dot com 2006-01-08 13:49 ---
> Reopening since many of the intrinsics could still vectorize better.
Could help if you list specific functions that you expect to get vectorized. As
far as dotprod is concerned - if it's operating on flo
ty: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dorit at il dot ibm dot com
GCC build triplet: ppc64-yellowdog-linux
GCC host triplet: ppc64-yellowdog-linux
GCC target triplet: ppc64-yellowdog-linux
http://g
--- Comment #19 from dorit at il dot ibm dot com 2006-07-23 19:03 ---
> The fix we've agreed is best in principle is to speculatively increase
> the DECL_ALIGN of vectorisable variables before compiling functions.
> Dorit says that there is a patch related to this on the a
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dorit at il dot ibm dot com
GCC build triplet: powerpc-linux
GCC host triplet: powerpc-linux
GCC target triplet: powerpc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #25 from dorit at il dot ibm dot com 2006-08-07 07:09 ---
(In reply to comment #24)
> Fixed, a new different bug for the missed optimization should be opened.
It's PR28628.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27770
--- Comment #43 from dorit at il dot ibm dot com 2006-08-07 20:35 ---
> I'm all for this. info gcc says that w/o a guarantee of alignment, loops are
> duped, with an if selecting between vector and scalar loops, is this not
> accurate?
yes
>I spent a day try
: dorit at il dot ibm dot com
GCC build triplet: powerpc-linux
GCC host triplet: powerpc-linux
GCC target triplet: powerpc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28643
--- Comment #3 from dorit at il dot ibm dot com 2006-08-08 07:38 ---
> Err, SSA copy prop should be enough, actually, since after copy-prop,
> the phi will have no users (and they shouldn't care about code with no
> uses that doesn't access memory).
> Though it&#
--- Comment #55 from dorit at il dot ibm dot com 2006-08-09 19:10 ---
Subject: Re: [4.0/4.1 Regression] gcc 4 produces worse x87 code
on all platforms than gcc 3
>
> Here's some questions I need to figure out:
> (1) Why do I have to throw the -funsafe-math-optimiz
--- Comment #9 from dorit at il dot ibm dot com 2006-08-31 08:08 ---
I have been unsuccessful in reproducing this problem on a i386-redhat-linux.
I don't get a failure compiling the testcase from comment 8.
I tried to compile the testcase from comment 7 and got the following e
--- Comment #10 from dorit at il dot ibm dot com 2006-08-31 08:22 ---
I think this can be closed?
(I opened a missed-optimization PR instead - PR28643)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26969
--- Comment #12 from dorit at il dot ibm dot com 2006-09-01 05:43 ---
oops - I didn't notice it was open against 4.1.
So hopefully porting Victor's patch to 4.1 would fix it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26969
--- Comment #4 from dorit at il dot ibm dot com 2006-09-11 10:57 ---
> You could help by looking at the source code (there are only a few dozens
> places mentioning flag_unsafe_math_optimizations) and auditing which places
> would be more suited to a new flag_reassociate_fp
Summary: missed optimization: redundant casts prevent
vectorization
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot o
--- Comment #4 from dorit at il dot ibm dot com 2006-09-21 19:30 ---
By the way, the testcase gets vectorized if you compile with -fwrapv.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29170
nment
support in the vectorizer
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dorit at i
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dorit at il dot ibm dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29269
--- Comment #11 from dorit at il dot ibm dot com 2007-02-06 08:18 ---
(In reply to comment #10)
> One thing I can think of that this description misses is that the two
> pointers must be based-on *different* restrict-qualified pointers, unless
> that case is already handled
--- Comment #3 from dorit at il dot ibm dot com 2007-02-12 10:11 ---
I'll look into it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30771
--- Comment #4 from dorit at il dot ibm dot com 2007-02-12 14:23 ---
I'm testing the patch below. (wasn;t able to reproduce the problem in the
attched testcase, but here's a reduced testcase for the problem that Richi
described - thanks!:
int a[128];
int
main()
{
short i;
--- Comment #3 from dorit at il dot ibm dot com 2007-02-15 10:21 ---
I'll look into it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30795
--- Comment #4 from dorit at il dot ibm dot com 2007-02-18 16:42 ---
patch: http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01555.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30795
--- Comment #2 from dorit at il dot ibm dot com 2007-02-18 21:50 ---
I was able to reproduce it. Here's a reduced testcase:
void dacP98FillRGBMap( unsigned char *pBuffer )
{
unsigned long dw, dw1;
unsigned long *pdw = (unsigned long *)(pBuffer);
for( dw = 256, dw1 =
--- Comment #3 from dorit at il dot ibm dot com 2007-02-19 08:28 ---
> Looks like possibly some bad interaction between vectorization of induction
> and
> vectorization of strided-access. Will investigate.
I looked into it with Ira, and looks like the problem is th
--- Comment #2 from dorit at il dot ibm dot com 2007-02-19 12:45 ---
Reduced testcase:
int foo (int ko)
{
int j,i;
for (j = 0; j < ko; j++)
i += (i > 10) ? -5 : 7;
return i;
}
Looking into it...
--
dorit at il dot ibm dot com changed:
What|R
--- Comment #3 from dorit at il dot ibm dot com 2007-02-19 12:56 ---
(In reply to comment #0)
Thanks for exercising the vectorizer and reporting these bugs!
> On the wider issue of the quality of the vectorizer, I
> have thrown most of Suse Linux 10.3 at it and it has crashed
--- Comment #5 from dorit at il dot ibm dot com 2007-02-19 14:12 ---
Looks like I wasn't careful enough with my fix for PR30771. Here is a fix for
that fix I'm now testing:
Index: tree-vect-analyze.c
===
---
--- Comment #6 from dorit at il dot ibm dot com 2007-02-20 22:56 ---
proposed patches - http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01734.html
> I have thrown most of Suse Linux 10.3 at it and it has crashed
> in a few places.
would you mind giving these patches a try? (to see
--- Comment #8 from dorit at il dot ibm dot com 2007-02-21 19:31 ---
> Is this acceptable ?
sure, thanks
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30858
--- Comment #5 from dorit at il dot ibm dot com 2007-03-05 20:15 ---
I'm travelling now, but can prepare a fix when I'm back (next week).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31041
--- Comment #4 from dorit at il dot ibm dot com 2007-03-14 12:13 ---
I also saw this on powerpc64, on a different testcase (vectorizing longs with
-m64). seems like constant propagation during dom3 propagates the vector
initializer into a BIT_FIELD_EXPR, which results in invalid gimple
--- Comment #5 from dorit at il dot ibm dot com 2007-03-14 12:29 ---
this is the testcase I have ICE-ing on powerpc64-yellowdog, when compiled with
-ftree-vectorize -maltivec -m64 -O2:
long stack_vars_sorted[32];
void partition_stack_vars (long stack_vars_num)
{
long si, n
--- Comment #7 from dorit at il dot ibm dot com 2007-03-24 08:00 ---
patch: http://gcc.gnu.org/ml/gcc/2007-03/msg00918.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30784
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dorit at il dot ibm dot com
GCC build triplet: i386-linux
GCC host triplet: i386-linux
GCC target triplet: i386-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31333
verity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dorit at il dot ibm dot com
GCC build triplet: powerpc-linux
GCC host triplet: powerpc-linux
GCC target triplet: powerpc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31334
--- Comment #4 from dorit at il dot ibm dot com 2007-04-03 19:56 ---
yes, this is indeed a known problem (I don't know if there's a PR open for it).
It is one of the tree-ifcvt enhancements that Victor was going to tackle for
4.3 (item (2.3) in http://gcc.gn
--- Comment #6 from dorit at il dot ibm dot com 2007-04-03 20:22 ---
So I see Devang had sent a patch for this over a year ago:
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00167.html
I don't know what ever happened to it.
Maybe you want to give it a try? (you may need to implemen
--- Comment #8 from dorit at il dot ibm dot com 2007-04-03 20:46 ---
(In reply to comment #7)
> Something like:
> (define_insn_and_split "altivec_dup"
> [(set (match_operand:V 0 "register_operand" "v")
> (vec_duplicate: (match_operand:
--- Comment #4 from dorit at il dot ibm dot com 2007-04-14 09:38 ---
> I think the only thing that really matters is that the loop is vectorized. I
> don't think the alignment details are important checking, even on platforms
> where they are relevant. So we should remove
--- Comment #5 from dorit at il dot ibm dot com 2007-04-17 07:22 ---
> Doing cast motion actually causes about 25 *more* failures in the vectorizer
> testsuite.
> I'm closing this as won't fix since it seems there was no other reason to do
> this.
can you pleas
--- Comment #6 from dorit at il dot ibm dot com 2007-04-17 07:38 ---
> can you please send me the patch so that I could look at this failures before
> you close this PR?
I'm going over my inbox top down, so I just saw that you had laready sent the
patch... so I will l
--- Comment #7 from dorit at il dot ibm dot com 2007-04-17 19:31 ---
> so I will look into it.
(for reference: http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01103.html).
So I guess this should be handled somewhere else. I'll open a new
missed-optimization PR instead (not aga
--- Comment #2 from dorit at il dot ibm dot com 2007-04-17 20:10 ---
> 2 more are under investigation:
> no-section-anchors-vect-69.c
> vect-reduc-dot-u16a.c
In the first testcase, the vectorizer can only prove that the data reference in
the third loop is aligned on 8 bytes
--- Comment #1 from dorit at il dot ibm dot com 2007-04-18 06:42 ---
could you please provide the .vect dump file, as generated with
-fdump-tree-vect-details?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31615
--- Comment #3 from dorit at il dot ibm dot com 2007-04-18 10:18 ---
> Created dump file using -fdump-tree-vect-details
thanks. So I don't understand why we expect to version for 3 different
data-references, since there are only 2 in the loop that is vectorized. But
then I wo
--- Comment #5 from dorit at il dot ibm dot com 2007-04-19 07:27 ---
(In reply to comment #4)
> (In reply to comment #3)
> > But then I wonder why we don't see the same failure on ia64?
> Because the failing part of the testcase is only done on ilp32 targets:
> ! {
--- Comment #7 from dorit at il dot ibm dot com 2007-04-25 21:30 ---
> Are you going to submit/install your patch?
yes, I'll go ahead and submit the patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31615
--- Comment #3 from dorit at il dot ibm dot com 2007-04-26 19:34 ---
Created an attachment (id=13450)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13450&action=view)
patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31699
--- Comment #4 from dorit at il dot ibm dot com 2007-04-26 19:37 ---
I'm testing the attched patch. The problem is that we don't compute the peel
factor correctly (when peeling to align a store) when we have multiple
data-types in the loop (the computation assumes that VF is
--- Comment #4 from dorit at il dot ibm dot com 2007-04-27 05:44 ---
patch: http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01739.html
requires retesting on ia64 before I can commit it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31589
--- Additional Comments From dorit at il dot ibm dot com 2005-03-14 20:01
---
The problem is that we take the size_type of a void type, and pass null to
fold_convert in vect_analyze_pointer_ref_access.
So one thing to do is to make sure that we're dealing with a complete
--- Additional Comments From dorit at il dot ibm dot com 2005-03-17 20:51
---
patch: http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01675.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20474
--- Additional Comments From dorit at il dot ibm dot com 2005-03-17 20:57
---
can you please send the output of compiling with -fdump-tree-vect-details?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20501
--- Additional Comments From dorit at il dot ibm dot com 2005-03-20 12:26
---
Thanks.
This patch should fix the problem (the message "Alignment of access forced
using peeling" should not be printed when we're not going to vectorize the loop
due to unsupported unalign
--- Additional Comments From dorit at il dot ibm dot com 2005-03-22 10:54
---
patch: http://gcc.gnu.org/ml/gcc-patches/2005-03/msg02063.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20501
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dorit at il dot ibm dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: powerpc-apple-darwin7.7.0
GCC host triplet: powerpc-apple-darwin7.7.0
GCC target triplet: powerpc-apple-darwin7.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20603
--- Additional Comments From dorit at il dot ibm dot com 2005-03-27 12:36
---
patch: http://gcc.gnu.org/ml/gcc-patches/2005-03/msg02442.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20626
--- Additional Comments From dorit at il dot ibm dot com 2005-03-31 12:58
---
Another testcase that exhibits a similar problem: vect-5.f90
(patch: http://gcc.gnu.org/ml/gcc-patches/2005-03/msg02840.html)
On powerpc64-linux (lp64) the second loop is not vectorized because the data
--- Comment #6 from dorit at il dot ibm dot com 2007-05-02 20:38 ---
patch: http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00111.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31699
--- Comment #2 from dorit at il dot ibm dot com 2007-05-08 21:00 ---
Here is what happens in the three loops that don't get vectorized:
(1) the loop in testvectdp2:
This is the loop we analyze:
# prephitmp.192_37 = PHI
# i_1 = PHI <1(3), i_44(5)>
:;
D.1437_32
ut
of loops
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dorit at il dot ibm d
--- Comment #8 from dorit at il dot ibm dot com 2007-05-09 07:14 ---
> So I guess this should be handled somewhere else. I'll open a new
> missed-optimization PR instead (not against PRE this time). thanks.
This is now PR31873
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25809
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dorit at il dot ibm dot com
GCC build triplet: spu
GCC host triplet: spu
GCC target triplet: spu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31945
normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dorit at il dot ibm dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31946
--- Comment #3 from dorit at il dot ibm dot com 2007-05-16 20:45 ---
(In reply to comment #2)
> Here is what happens in the three loops that don't get vectorized:
> (1) the loop in testvectdp2:
...
> so the vectorizer is ok, except that in this case D.1437_32 doesn
ersion: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dorit at il dot ibm dot com
GCC build triplet: powerpc-linux
GCC host triplet: powerpc-linux
GCC targe
--- Comment #3 from dorit at il dot ibm dot com 2007-06-06 03:28 ---
(In reply to comment #1)
veclower expands things when it wrongly concludes that they are not supported
by the target in vecor mode. For demotion/promotion/conversion kinda operations
this may be because it does not
--- Comment #5 from dorit at il dot ibm dot com 2007-06-06 08:33 ---
(In reply to comment #4)
> (In reply to comment #3)
> > Probably something similar is required for the VEC_UNPACK_FLOAT_*_EXPR
> > tree-codes ?
> But these tree-codes are already there:
sorry, I gues
--- Comment #4 from dorit at il dot ibm dot com 2007-06-07 18:40 ---
You're right. I'm testing this obvious patch:
Index: tree-vect-analyze.c
===
*** tree-vect-analyze.c (revision 125526)
--- tree-vect-analyze.
--- Comment #4 from dorit at il dot ibm dot com 2007-06-12 17:46 ---
it's on my (long) todo list...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32309
--- Comment #1 from dorit at il dot ibm dot com 2007-06-13 08:41 ---
Sorry about the breakage. Does it work for you if you change the testcase as
follows?:
Index: pr32224.c
===
--- pr32224.c (revision 125641)
+++ pr32224
--- Comment #2 from dorit at il dot ibm dot com 2007-06-18 11:03 ---
I see this in the vectorizer dump file (with mainline from a few days ago):
(compute_affine_dependence
(stmt_a =
D.3027_19 = p_7->a[D.3026_18])
(stmt_b =
p_7->a[D.3025_17] = D.3027_19)
Data ref a:
(Da
--- Comment #4 from dorit at il dot ibm dot com 2007-06-18 11:08 ---
I see this in the vectorizer dump file (with mainline from a few days ago):
(compute_affine_dependence
(stmt_a =
D.1423_50 = (*a_49(D))[D.1422_48])
(stmt_b =
(*a_49(D))[D.1420_51] = D.1425_54)
Data ref a:
(Data
--- Comment #5 from dorit at il dot ibm dot com 2007-06-27 11:57 ---
(In reply to comment #4)
> (In reply to comment #3)
> > The problem is in -ftree-vectorize
> The difference is, that without -ftree-vectorize the inner loop (do k = 1, 9)
> is completely unr
--- Comment #19 from dorit at il dot ibm dot com 2007-06-29 16:46 ---
testing this patch for Altivec:
Index: config/rs6000/altivec.md
===
*** config/rs6000/altivec.md(revision 126053)
--- config/rs6000/altivec.md
--- Comment #12 from dorit at il dot ibm dot com 2007-07-01 09:30 ---
> Subject: Re: -ftree-vectorize results in internal compiler error on AMD64
> Zdenek's patch for cleaning the dataref analysis is also fixing this bug.
> http://gcc.gnu.org/ml/gcc-patches/2007-05/msg
--- Additional Comments From dorit at il dot ibm dot com 2005-09-08 13:54
---
(In reply to comment #4)
> This bit is actually included in Keith's versioning-for-alignment patch
> (http://gcc.gnu.org/ml/gcc-patches/2005-08/msg01372.html), which hopefully is
> going to be
--- Additional Comments From dorit at il dot ibm dot com 2005-09-19 06:52
---
do these ia64 reduction testcase failures still occur?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23188
--- Additional Comments From dorit at il dot ibm dot com 2005-09-19 06:54
---
does this ia64 reduction testcase failure still occur?
--
What|Removed |Added
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dorit at il dot ibm dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: ppc64-yellowdog-li
--- Additional Comments From dorit at il dot ibm dot com 2005-09-21 13:16
---
Indeed. This bug can be closed now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23989
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dorit at il dot ibm dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: ppc64-yellowdog-li
--- Additional Comments From dorit at il dot ibm dot com 2005-09-21 13:46
---
I don't know how this happened - I didn't mean to open this PR again. This
should be closed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23997
--- Comment #5 from dorit at il dot ibm dot com 2005-10-06 15:45 ---
For some targets the vect_no_align keyword means that the target intrinsically
cannot support the feature, and for other targets it means that the feature can
potentially be supported but something is still missing in
--- Comment #1 from dorit at il dot ibm dot com 2005-10-06 15:46 ---
see patch in: http://gcc.gnu.org/ml/gcc-patches/2005-10/msg00284.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24108
--- Comment #2 from dorit at il dot ibm dot com 2005-10-12 07:23 ---
There are two problems here:
1) This is the data-reference structure created (using the same testcase but
with floats instead of doubles):
Created dr for A[D.1705_7]
base_address: &A
of
--- Comment #2 from dorit at il dot ibm dot com 2005-11-03 17:11 ---
vectorization of type conversions has recently been added to autovect-branch.
It requires modeling the respective unpack and pack optabs in the machine
description.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Additional Comments From dorit at il dot ibm dot com 2005-07-26 13:59
---
Subject: Re: [4.1 Regression] wrong code for casts and
scev
Hi Sebastian,
The modifications you suggest will make the tests uninteresting - they were
introduced with unknown loop-bound/offset on
--- Additional Comments From dorit at il dot ibm dot com 2005-07-27 10:11
---
patch:
http://gcc.gnu.org/ml/gcc-patches/2005-07/msg01776.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23083
--- Additional Comments From dorit at il dot ibm dot com 2005-07-27 10:35
---
patch:
http://gcc.gnu.org/ml/gcc-patches/2005-07/msg01776.html
(I should have referred to it as a patch for PR23073 rather than the duplicate
PR23083)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23073
--- Additional Comments From dorit at il dot ibm dot com 2005-07-27 10:38
---
This is triggered by tree-ifcvt (which is enabled by -ftree-vectorize)
--
What|Removed |Added
1 - 100 of 200 matches
Mail list logo
