> When a loop is vectorized, some statements are removed from the basic
> blocks, but the vectorizer information attached to these BBs is never
> freed. This is because the attached information is freed by walking
> the statements of the basic blocks: see tree-vectorizer.c:1750, but
> the transfor
I have obtained the same error on my ppc64 yellow dog linux:
/bin/sh ./libtool --mode=compile
/home/victork/mainline-vanila/build/./gcc/gfortran
-B/home/victork/mainline-vanila/build/./gcc/
-B/home/victork/mainline-vanila/usr/ppc64-yellowdog-linux/bin/
-B/home/victork/mainline-vanila/usr/ppc64-y
Just use your cross-compiler to build a compiler for the target system
that'll run on the target system. Then it could be good idea to use
new native compiler on its hardware to rebuild gcc once again natively.
Two compilers from last two steps should be identical. It's a good way
to make sure yo
Richard Guenther <[EMAIL PROTECTED]> wrote on 06.02.2007 11:19:15:
> On Tue, 6 Feb 2007, Dorit Nuzman wrote:
> > After sleeping on it, it actually makes a lot of sense to me to
schedule
> > complete loop unrolling before vectorization - I think it would either
> > simplify loops (sometimes creatin
I've reopened a new branch autovect-branch, taken off the trunk as of
today.
The branchpoint revision is 120362. The old branch went way out of synch
with mainline so I've moved it to branches/dead/old-autovect-branch in svn
repository.
New autovect-branch has initialized merge tracking support
[EMAIL PROTECTED] wrote on 20-04-2006 12:47:54 AM:
>
> 3) autovectorization improvements
>
> Good autovectorization is becoming ever more-important in performance
> evaluation. Is there someone who can review this patch?
>
> Are there other things that are approximately ready for inclusion that
