This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [autovect] [patch] branch merge
- From: Keith Besaw <kbesaw at us dot ibm dot com>
- To: Dorit Naishlos <DORIT at il dot ibm dot com>
- Cc: gcc-patches at gcc dot gnu dot org, Ira Rosen <IRAR at il dot ibm dot com>
- Date: Wed, 13 Apr 2005 18:39:07 -0500
- Subject: Re: [autovect] [patch] branch merge
Keith Besaw
Dept. GZA (Translator)
(507)253-3628 t/l 553-3628
eMail:
Lotus: Keith Besaw/Rochester/IBM
Internet: kbesaw@us.ibm.com
Dorit Naishlos/Haifa/IBM wrote on 04/13/2005 02:33:41 AM:
> thanks
>
> >
> > Ran the vector tests with the fix for vect-95.c. Only failures are
now:
> > FAIL: gcc.dg/vect/no_version/pr18536.c scan-tree-dump-times
> > vectorized 1 loops 1
> > FAIL: gcc.dg/vect/no_version/vect-39.c scan-tree-dump-times
> > vectorized 1 loops 1
>
> this is ok
>
> > FAIL: gcc.dg/vect/no_version/vect-92.c execution test
> >
>
> I don't see this failure in current autovect snapshot. ?
>
> dorit
Looking back through my saved test results vect-92.c has been failing
since 3/24/05 in autovect and 3/28/05 in the mainline. Sorry, I guess
I thought it was a known problem. My output shows the following
vectorization notes
vect-92.c:57: note: Alignment of access forced using peeling.
vect-92.c:57: note: LOOP VECTORIZED.
vect-92.c:63: note: not vectorized: multiple exits.
vect-92.c:54: note: vectorized 1 loops in function.:
vect-92.c:17: note: Alignment of access forced using peeling.
vect-92.c:17: note: LOOP VECTORIZED.
vect-92.c:25: note: not vectorized: multiple exits.
vect-92.c:14: note: vectorized 1 loops in function.
vect-92.c:37: note: Alignment of access forced using peeling.
vect-92.c:37: note: LOOP VECTORIZED.
vect-92.c:45: note: not vectorized: multiple exits.
vect-92.c:34: note: vectorized 1 loops in function.
And execution does an Abort (core dumped).
Today I'm trying to finish up getting loop versioning ready to submit
to the maininline, but when I start the testing tomorrow I can try
and take a closer look at what's wrong with vect-92.c.
A quick look at vect-92.c shows the following:
#define N 256
...
int main (void)
{
int i;
afloat a[N];
afloat b[N] = {0,3,6,9,12,15,18,21,24,27,30,33,36,39,42,45,48,51,54,57};
afloat c[N] = {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19};
...
main3 (a,b,c,N);
...
int
main3 (afloat * __restrict__ pa, afloat * __restrict__ pb, afloat *
__restrict__ pc, int n)
{
int i;
for (i = 0; i < n; i++)
{
pa[i+1] = pb[i+1] * pc[i+1];
}
/* check results: */
for (i = 0; i < n; i++)
{
if (pa[i+1] != (pb[i+1] * pc[i+1]))
abort ();
}
return 0;
}
b and c are automatic arrays with only 20 elements being initialized.
I don't know if the remaining 236 elements are always initialized to zero
because the arrays are automatic or what happens to the multiplies and
tests with potentially garbage/un-normalized/NaN data.