--- Additional Comments From dorit at il dot ibm dot com 2005-07-27 14:27
---
This patch should fix it:
Index: tree-vectorizer.c
===
RCS file: /cvs/gcc/gcc/gcc/tree-vectorizer.c,v
retrieving revision 2.105
diff -c -3 -p
--- Additional Comments From dorit at il dot ibm dot com 2005-07-28 12:34
---
patch: http://gcc.gnu.org/ml/gcc-patches/2005-07/msg01879.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22506
--- Additional Comments From dorit at il dot ibm dot com 2005-08-07 14:37
---
Looks like this happens during tree-if-conversion:
#0 internal_error (gmsgid=0x53b138 "in %s, at %s:%d")
at ../../gcc/gcc/diagnostic.c:535
#1 0x0027a4fc in get_loop_body (loop=0x42105990) at ../
--- Additional Comments From dorit at il dot ibm dot com 2005-08-09 15:38
---
I was able to reproduce the error on powerpc-drawin using the first testcase
from comment 3 for PR22543.
I was also able to pin down the patch that triggered/exposed this problem:
2005-07-09 Diego Novillo
--- Additional Comments From dorit at il dot ibm dot com 2005-08-09 17:14
---
> I'm not sure what relationship this patch has wrt this PR -- I filed the PR
> on 2005-06-28, so before Diego's patch. It may well have exposed a separate
> problem, though.
>
I
--- Additional Comments From dorit at il dot ibm dot com 2005-08-14 14:00
---
patch: http://gcc.gnu.org/ml/gcc-patches/2005-08/msg00826.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8
--- Additional Comments From dorit at il dot ibm dot com 2005-08-16 08:48
---
oops, I sent the worng patch (I also got this bootstrap error, and fixed it,
but sent the older patch by mistake) - will resend
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8
--- Additional Comments From dorit at il dot ibm dot com 2005-08-16 16:41
---
patch: http://gcc.gnu.org/ml/gcc-patches/2005-08/msg00979.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8
--- Additional Comments From dorit at il dot ibm dot com 2005-08-28 13:47
---
The patch below fixes the problem.
We fail on this assert:
gcc_assert (evolution_part != NULL_TREE);
in 'vect_update_ivs_after_vectorizer'.
This happens because we a
--- Comment #11 from dorit at il dot ibm dot com 2007-10-30 05:48 ---
(In reply to comment #6)
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)?
Any idea why the fix you committed doesn't
--- Comment #5 from dorit at il dot ibm dot com 2006-01-24 09:10 ---
Patch:
Index: tree-vect-patterns.c
===
--- tree-vect-patterns.c(revision 109954)
+++ tree-vect-patterns.c(working copy)
@@ -243,7 +243,8
--- Comment #1 from dorit at il dot ibm dot com 2006-01-26 09:07 ---
Can you please send the dump files generated by -fdump-tree-vect-details?
reduc-dot-s16.c needs the sdot_prodv4hi pattern, which is implemented for ia64,
so I'd expect one loop to be vectorized. I wonder what&
--- Comment #6 from dorit at il dot ibm dot com 2006-02-08 14:17 ---
(In reply to comment #4)
> ... This happens
> because the IA-64 port defines the widen_ssumv4hi3 pattern. The IA-64 port is
> the only one that defines this pattern, and hence is probably the only port
> &
--- Comment #7 from dorit at il dot ibm dot com 2006-02-08 14:19 ---
(In reply to comment #5)
Will take care of that.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25918
--- Comment #6 from dorit at il dot ibm dot com 2006-02-13 16:23 ---
(In reply to comment #5)
> Probably related to
> http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00446.html
Would you expect then that calling mark_new_vars_to_rename, like you did in
your patch, will fix this p
--- Comment #2 from dorit at il dot ibm dot com 2006-02-19 08:50 ---
This happens because we actually rely on dce taking place after the vectorizer
to clean up dead code. When we detect a pattern (widneing-summation in this
case) we create a "dummy" stmt ("pattern-stmt&qu
--- Comment #2 from dorit at il dot ibm dot com 2006-02-19 15:34 ---
The problem is that during dce the call to is_hidden_global_store returns false
cause the tag is not marked as global/static.
This seems to fix it:
Index: tree-ssa-alias.c
--- Comment #10 from dorit at il dot ibm dot com 2006-02-19 16:10 ---
so maybe if an SFT has may-aliases then new_type_alias should add the
may-aliases of the SFT as may-aliases of the new tag, instead of adding the SFT
as a may-alias of the new tag. ?
There's a comme
--- Comment #1 from dorit at il dot ibm dot com 2006-02-20 16:45 ---
Looks like the vectorizer detects a strided access in this testcase. Strided
accesses are not entirely supported for SSE right now (work in progress...),
but it is enabled, so currently all strided testcases brake on
--- Comment #2 from dorit at il dot ibm dot com 2006-02-20 17:09 ---
Actually there's this patch by rth that seems to fix this ICE; it's from a
while back, I don't think it was fully tested at the time, and I'm not sure it
provides all the missing bits/f
--- Comment #3 from dorit at il dot ibm dot com 2006-02-21 22:01 ---
patch:
http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01710.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26359
--- Comment #3 from dorit at il dot ibm dot com 2006-02-21 22:02 ---
patch:
http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01713.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26360
--- Comment #2 from dorit at il dot ibm dot com 2006-02-26 11:01 ---
For -ftree-vectorizer-verbose=1 the vectorizer reports each loop that got
vectorized, and also the total number of loops that got vectorized, even if
that number is zero. If preferable, we can report that 0 loops got
--- Comment #3 from dorit at il dot ibm dot com 2006-02-26 11:05 ---
patch: http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01905.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26419
--- Comment #11 from dorit at il dot ibm dot com 2006-02-28 08:26 ---
Created an attachment (id=10935)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10935&action=view)
tentative patch
I get a similar error message when trying to bootstrap mainline with
vectorization
--- Comment #13 from dorit at il dot ibm dot com 2006-03-01 12:35 ---
So I'll submit the patch to gcc-patches for approval. Can someone please check
if this patch actually solves this PR?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26197
--- Additional Comments From dorit at il dot ibm dot com 2005-04-27 08:59
---
(In reply to comment #18)
> I submitted a patch, http://gcc.gnu.org/ml/gcc-patches/2005-04/msg02284.html,
> but as the mail says it results in a lot of regressions in the compat and
> vector tests.
--- Additional Comments From dorit at il dot ibm dot com 2005-05-02 14:14
---
see patch: http://gcc.gnu.org/ml/gcc-patches/2005-04/msg02874.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20794
--- Additional Comments From dorit at il dot ibm dot com 2005-05-02 14:51
---
I get the following bootstrap failure on powerpc-apple-darwin, with "-O2 -ftree-
vectorize":
../../gcc/gcc/builtins.c: In function 'fold_builtin_1':
../../gcc/gcc/builtins.c:8451: internal
--- Additional Comments From dorit at il dot ibm dot com 2005-05-02 16:06
---
I can't reproduce this problem - not for the testcase in comment #3 and not for
the testcase in comment #5 (I tried on i686-pc-linux-gnu and on powerpc-apple-
darwin). Does the problem still
--- Additional Comments From dorit at il dot ibm dot com 2005-05-02 16:27
---
Thanks for the testcase.
I tried reproducing the problem on i686-pc-linux-gnu with today's snapshot of
4.1, and also with today's snapshot of 4.0 (gcc version 4.0.1 20050502
(prerelease))
--- Additional Comments From dorit at il dot ibm dot com 2005-05-24 11:53
---
I can reproduce this problem on powerpc-apple-darwin, even without the
options "-maltivec -mabi-altivec" (which means that no simd vectorization takes
place). What happens is that the scalar_evol
--- Additional Comments From dorit at il dot ibm dot com 2005-05-24 12:54
---
> Is there a rule that ggc_collect should not be called during loop
optimizations?
I don't know. (Zdenek?)
I think passes within the loop optimizer can assume that the scev information
cached in
--- Additional Comments From dorit at il dot ibm dot com 2005-05-24 15:16
---
(In reply to comment #7)
> > >So at the moment, you cannot run ggc_collect inside loop opts.
> > >
> > >
> > Is this going to change?
> >
> > If not, I guess rem
--- Additional Comments From dorit at il dot ibm dot com 2005-05-25 07:28
---
> Actually, this is a bug in the vectorizer code to update PHIs in duplicate
> loops. forwprop AFAICT is just exposing the latent vectorizer bug.
> >From what I've been able to dete
--- Additional Comments From dorit at il dot ibm dot com 2005-05-26 12:02
---
patch: http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02477.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21639
timization
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21805
--- Additional Comments From dorit at il dot ibm dot com 2005-05-30 13:04
---
These failures should have been fixed after this:
http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02756.html
With the fix above I no longer see these testcase failures on powerpc-apple-
darwin, but the ICEs
--- Additional Comments From dorit at il dot ibm dot com 2005-05-30 13:10
---
> Confirmed, this is most likely the same as PR 21653.
Indeed looks related, but a patch that fixed PR21653 did not fix this PR. I
also checked if the follow-on fix - http://gcc.gnu.org/ml/gcc-patches/2
--- Additional Comments From dorit at il dot ibm dot com 2005-05-30 14:35
---
I can't reproduce this ICE with mainline snapshot from today. (I was able to
reproduce it a few days ago, but not anymore).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21734
--- Additional Comments From dorit at il dot ibm dot com 2005-05-30 14:47
---
> crafty_bug.c:31: internal compiler error: tree check: expected ssa_name, have
> var_decl in is_old_name, at tree-into-ssa.c:467
> SPEC CPU2000 tests gcc, crafty, and mesa all get this ICE.
I
--- Additional Comments From dorit at il dot ibm dot com 2005-05-30 15:08
---
> I also checked if the follow-on fix - http://gcc.gnu.org/ml/gcc-patches/2005-
> 05/msg02478.html resolves this problem, but it doesn't.
Actually, I think the patch above
(http://gcc.gnu.org/ml/
--- Additional Comments From dorit at il dot ibm dot com 2005-06-01 11:13
---
I can reproduce this on powerpc-apple-darwin.
Maybe a duplicate of PR21831.
Hopefully will be resolved by Keith's work
(http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02478.html)
--
http://gcc.gn
--- Additional Comments From dorit at il dot ibm dot com 2005-06-01 11:24
---
I think Keith is looking into these SPEC ICEs on powerpc-linux.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21155
--- Additional Comments From dorit at il dot ibm dot com 2005-06-01 13:20
---
thanks, reproduced.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21734
--- Additional Comments From dorit at il dot ibm dot com 2005-06-01 13:22
---
> Note that if !new_ssa_name, we continue the loop without ever
> adding the PHI argument. The net result being that we have a
> PHI where PHI_ARG_DEF for one of the PHI's incoming edges is
--- Additional Comments From dorit at il dot ibm dot com 2005-06-01 19:14
---
> Please, remember to add both the new and the old testcase to the testsuite.
patch: http://gcc.gnu.org/ml/gcc-patches/2005-06/msg00110.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21734
--- Additional Comments From dorit at il dot ibm dot com 2005-06-07 07:35
---
> I tried compiling x.ii on power-pc and couldn't reproduce the problem.
> I don't know if this means that the problem goes away with recent
> patches or that it only occurs when vectori
--- Additional Comments From dorit at il dot ibm dot com 2005-06-07 07:42
---
> I tried vect-97.c on power-pc and couldn't reproduce the problem.
> I don't know if this means that the problem goes away with recent
> patches or that it only occurs when vectorizin
--- Additional Comments From dorit at il dot ibm dot com 2005-06-07 07:50
---
This testcase doesn't get vectorized anymore, after my patch from
http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02817.html:
"pr21859.f90:6: note: not vectorized: redundant loop. no profit to
--- Additional Comments From dorit at il dot ibm dot com 2005-06-07 09:58
---
> I tried on powerpc-apple-darwin and on i686-pc-linux-gnu - couldn't reproduce
> the failure
correction - can't reproduce the failure on powerpc,
but I do see the ICE on i686-pc-lin
--- Additional Comments From dorit at il dot ibm dot com 2005-06-07 10:13
---
I also see this on powerpc-apple-darwin:
g++ -O -ftree-vectorize -maltivec pr21933.cc
pr21933.cc: In function 'void baz()':
pr21933.cc:23: internal compiler error: tree check: expected ssa_
--- Additional Comments From dorit at il dot ibm dot com 2005-06-07 19:49
---
> When were you seeing it on those platforms? My monitoring has never shown
> this as an i686-pc-linux-gnu failure, but it still fails on ia64-hpux,
> both -milp32 and -mlp64, as of today&#
--- Additional Comments From dorit at il dot ibm dot com 2005-06-09 08:45
---
patch: http://gcc.gnu.org/ml/gcc-patches/2005-06/msg00850.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21933
--- Additional Comments From dorit at il dot ibm dot com 2005-06-09 08:47
---
this patch: http://gcc.gnu.org/ml/gcc-patches/2005-06/msg00850.html seems to
fix this ICE.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21884
--- Additional Comments From dorit at il dot ibm dot com 2005-06-17 12:58
---
> bug.c: In function 'foo':
> bug.c:4: internal compiler error: in get_bb_copy, at cfg.c:1078
a bunch of vectorizer testcases are failing with this error on
i686-pc-linux-gnu and powerpc-da
--- Additional Comments From dorit at il dot ibm dot com 2005-01-09 16:35
---
vect-[46,50,52,58,60] don't fail anymore, and vect-[77,78] xfail on vectorizing
for lp62 targets, so I think we can classify this PR as missed-optimization
only, or close it and open a new (m
--- Additional Comments From dorit at il dot ibm dot com 2005-02-09 19:30
---
continued in this thread:
http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00196.html
and cmmitted:
http://gcc.gnu.org/ml/gcc-cvs/2005-02/msg00153.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18441
--- Additional Comments From dorit at il dot ibm dot com 2005-02-12 11:13
---
As far as I can see it's related to scalar evolution (nothing gets vectorized,
the ICE happens during the analysis stage of the vectorizer, when the
vectorizer calls analyze_scalar_evolution):
--- Additional Comments From dorit at il dot ibm dot com 2005-02-12 16:35
---
We fail to vectorize with:
wagi.cc:43: note: not vectorized: unhandled data ref: D.31081_39 = this_3->wagi
wagi.cc:43: note: bad data references.
The loop in question looks like this:
# i_1 = PHI ;
:;
--- Additional Comments From dorit at il dot ibm dot com 2005-02-12 20:38
---
> Well, we don't vectorize any loops as of today either... Sigh.
(just fyi:) I just checked on powerpc-darwin (but with NAG as fortran FE, not
gfortran), and these were reported as vectorized:
bea
--- Additional Comments From dorit at il dot ibm dot com 2005-02-15 08:44
---
This happens during tree-if-conversion pass (before vectorization) (tree-if-
conversion is enabled by -ftree-vectorize)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19952
--- Additional Comments From dorit at il dot ibm dot com 2005-02-15 13:23
---
I'm testing this patch (it solves this PR):
Index: tree-vectorizer.c
===
RCS file: /cvs/gcc/gcc/gcc/tree-vectorizer.c,v
retrieving rev
--- Additional Comments From dorit at il dot ibm dot com 2004-10-17 17:13 ---
Subject: Re: [4.0 Regression] ICE in vect_transform_stmt, at
tree-vectorizer.c:2625 (testcase included)
I'm testing a patch that fixes this problem - will submit it later today (
the problem is relat
atch along these lines shortly.
--
Summary: execution failure in vect-[20,22].c on ppc-linux
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: regression
AssignedTo: dorit
ppc-linux
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dorit at il dot ibm dot com
CC: gcc-bugs at gcc d
--- Additional Comments From dorit at il dot ibm dot com 2004-10-27 11:48 ---
(In reply to comment #7)
> Can anyone reproduce the problem on i686-linux (P4)?
I wasn't able to reporoduce it on i686-pc-linux-gnu.
This might be related to PR18173.
Is PREFERRED_STACK_
t accesses
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: irar at il dot ibm dot com
ReportedBy: dorit at il dot ibm dot com
CC: dorit a
--- Additional Comments From dorit at il dot ibm dot com 2004-10-27 14:41 ---
Created an attachment (id=7417)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7417&action=view)
testcase.
Forgot to mention - occurs when compiling with '-O2 -ftree-vectorize
-maltivec'.
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: dorit at il dot ibm dot com
ReportedBy: dorit at il dot ibm dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC bui
--- Additional Comments From dorit at il dot ibm dot com 2004-11-04 09:17 ---
Created an attachment (id=7471)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7471&action=view)
testcase
Here's a testcase that fails on execution with current mainline snapshot (no
need for
--- Additional Comments From dorit at il dot ibm dot com 2004-11-04 14:44 ---
patch: http://gcc.gnu.org/ml/gcc-patches/2004-11/msg00277.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18179
--- Additional Comments From dorit at il dot ibm dot com 2004-11-04 14:45 ---
patch: http://gcc.gnu.org/ml/gcc-patches/2004-11/msg00283.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18181
--- Additional Comments From dorit at il dot ibm dot com 2004-11-07 14:50
---
(1) The first (original) testcase does not get vectorized because
analyze_scalar_evolution is unable to analyze the access-function of the
pointers in the loop. For the pointer D.1780_5 it returns "D.1
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: dorit at il dot ibm dot com
ReportedBy: dorit at il dot ibm dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: powerpc-apple-darwin7.0.0
GCC host t
--- Additional Comments From dorit at il dot ibm dot com 2004-11-09 14:54
---
Created an attachment (id=7502)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7502&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18400
Severity: normal
Priority: P2
Component: regression
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: powerpc64-suse-linux
GCC host triplet: powerpc64-sus
--- Additional Comments From dorit at il dot ibm dot com 2004-11-15 18:53
---
(In reply to comment #2)
> At least on powerpc-darwin (with -m64) we now vectorize these loops but we
ICE because we have:
> pointer_type + int_type which is not valid and is even worse on 64bit targe
--- Additional Comments From dorit at il dot ibm dot com 2004-11-16 12:14
---
patch: http://gcc.gnu.org/ml/gcc-patches/2004-11/msg01301.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18403
--- Additional Comments From dorit at il dot ibm dot com 2004-11-16 12:47
---
Testcases vect-[77,77a,78].c don't get vectorized with -m64 because the access
function that the evolution analyzer returns for the pointers in these loops
looks like the following:
ib_16 + (aint *) (
--- Additional Comments From dorit at il dot ibm dot com 2004-11-17 11:09
---
(In reply to comment #1)
> PR 10469 looks like a testcase where this could improve the code generation.\
gcc.dg/vect/vect-25.c is a testcase too.
This is what is currently generated (the invariant is in
--- Additional Comments From dorit at il dot ibm dot com 2004-11-18 14:33
---
(In reply to comment #1)
> Confirmed, the problem I think is the same as the PPC64 problem in PR 18403
but I did not check the
> patch which will fix that one for sure.
That patch does not fix this p
--- Additional Comments From dorit at il dot ibm dot com 2004-11-18 21:12
---
patch:
http://gcc.gnu.org/ml/gcc-patches/2004-11/msg01512.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18536
--- Additional Comments From dorit at il dot ibm dot com 2004-11-18 21:56
---
> Note it works no when compiled with the C front-end but not with the C++
front-end.
> It is more related to PR 18546 than it is to PR18536.
This patch fixes the ICE:
http://gcc.gnu.org/ml/gcc-patche
--- Additional Comments From dorit at il dot ibm dot com 2004-11-19 18:24
---
(In reply to comment #5)
> (In reply to comment #2)
> > Subject: Re: Inefficient code generated by
> > -ftree-vectorize on Alpha
> > On Fri, 2004-11-19 at 00:04 +, pinskia a
--- Additional Comments From dorit at il dot ibm dot com 2004-11-23 19:48
---
just for the record - related comments from http://gcc.gnu.org/ml/gcc-
patches/2004-11/msg01394.html:
"
> > A question: how would you write a testcase that when compiled on
powerpc*
> > t
--- Additional Comments From dorit at il dot ibm dot com 2004-11-23 20:08
---
see - http://gcc.gnu.org/ml/gcc-patches/2004-11/msg01891.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18173
--- Additional Comments From dorit at il dot ibm dot com 2004-11-30 14:10
---
(In reply to comment #2)
> Subject: Bug 18173
> CVSROOT: /cvs/gcc
> Module name: gcc
> Changes by: [EMAIL PROTECTED] 2004-11-30 14:02:45
> Modified files:
> gcc
--- Additional Comments From dorit at il dot ibm dot com 2004-12-01 18:34
---
This patch should fix the problem:
Index: tree-vectorizer.c
===
RCS file: /cvs/gcc/gcc/gcc/tree-vectorizer.c,v
retrieving revision 2.42
diff -c
--- Additional Comments From dorit at il dot ibm dot com 2004-12-01 21:58
---
> I'll submit a patch to mainline shortly.
patch: http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00077.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18716
--- Comment #6 from dorit at il dot ibm dot com 2006-11-05 15:48 ---
(In reply to comment #5)
> This was something that slipped in, IIRC. I was of Ian's viewpoint, that
> may_alias_p should handle it, and it shouldn't be special to data-references.
yes, it was origi
ot org
ReportedBy: dorit at il dot ibm dot com
GCC build triplet: i?86-*-* and x86_64-*-*
GCC host triplet: i?86-*-* and x86_64-*-*
GCC target triplet: i?86-*-* and x86_64-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29777
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dorit at il dot ibm dot com
GCC build triplet: ia64-*-*
GCC host triplet: ia64-*-*
GCC target triplet: ia64-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29778
ity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dorit at il dot ibm dot com
GCC build triplet: ppc*-*-linux
GCC host triplet: ppc*-*-linux
GCC target triplet: ppc*-*-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29779
--- Comment #2 from dorit at il dot ibm dot com 2006-11-09 20:26 ---
> But these files can be succesfully vectorized using current (gcc version 4.3.0
> 20061109) version on i686:
> gcc -O2 -msse2 -ftree-vectorize -fdump-tree-vect-all vect-widen-mult-sum.c
> vect-widen-m
--- Comment #7 from dorit at il dot ibm dot com 2006-11-17 06:46 ---
(In reply to comment #6)
> This patch should fix the problem:
indeed it does, thanks!
are you going to submit it to mainline?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29779
--- Comment #12 from dorit at il dot ibm dot com 2006-12-06 22:22 ---
> By the way, you wrote 2006-11-17:
> > Should be submitted this weekend
> Any new ETA?
It was already submitted:
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00110.html
--
http://gcc.gnu.
--- Comment #11 from dorit at il dot ibm dot com 2006-12-07 20:19 ---
(In reply to comment #10)
> Using the three patches:
...
> gfortran is able to use sincos - and does so for my example (comment #0; the
> example, however, cannot be vectorized).
why? (what does -fdump-
--- Comment #16 from dorit at il dot ibm dot com 2006-12-12 20:59 ---
(In reply to comment #13)
Looks like what's blocking vectorization of the loop is:
sinc.f90:8: note: value used after loop.
sinc.f90:8: note: not vectorized: relevant stmt not supported: D.1408_32 =
(*radius_
--- Comment #8 from dorit at il dot ibm dot com 2007-01-07 20:22 ---
I'm testing this patch, that makes us more conservative, and concludes that two
pointers don't overlap only if both are "based on" restricted pointers, with
"based on" trivially implemen
101 - 200 of 200 matches
Mail list logo
