Bug#569436: blas: zgesvd seems to give incorrect results
Hi, I played with the example provided by Kumar Appaiah, and narrowed the problem down to zdrot; after copying zdrot.f into the same directory as zgesvd_ex.f: $ gfortran -O2 -c zgesvd_ex.f $ gfortran -O2 -c zdrot.f $ gfortran -o zgesvd_ex zgesvd_ex.o zdrot.o -llapack $ ./zgesvd_ex gives the expected result (with libblas3gf 1.2-4), but $ gfortran -O2 -ftree-vectorize -c zdrot.f $ gfortran -o zgesvd_ex zgesvd_ex.o zdrot.o -llapack $ ./zgesvd_ex gives the wrong result. This looks like a bug in the gcc vectorizer, and it cannot be reproduced with gcc 4.5 from experimental. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#569436: blas: zgesvd seems to give incorrect results
Dear Denis,
On Sat, Feb 27, 2010 at 09:22:53PM +0100, Denis Barbier wrote:
> > This was fantastic analysis. I actually would like to know how you
> > zeroed in onto zdrot to find the problem.
>
> Hi,
>
> I used brute force ;)
> libblas3gf 1.2-4 is installed on my system, object files from
> libblas3gf 1.2-3 have been unpacked into dir1, half files are moved
> into dir2. then I compiled
> gfortran zgesvd_ex.o dir1/*.o -llapack
> and by dichotomy found which object file is causing trouble.
Thanks for letting me know; I shall try to use this method the next time.
> > I shall now try to play around with zdrot to see if I can create a
> > test case which reproduces the bug, so that I can file a bug report
> > with GCC.
>
> I am afraid that this is not easy, and anyway GCC folks will discard
> your bugreport since this bug has been fixed in 4.5. But I am very
> interested to know the exact reason, and if there is a way to prevent
> this bug by modifying source files.
I have been trying, but I am unable to produce errors with my analysis
of zdrot individually. In the hope that someone else smarter than me,
can find a non-functional test case, I attach my source
code. Compiling it with make, and then make FFLAGS=-O3 should result
in some difference when the resulting executable is run for some test
cases, but which test case it is, I am unsure.
HTH, and thanks.
Kumar
--
Life's errors cry for the merciful beauty
that can modulate their isolation
into a harmony with the whole.
- Rabindranath Tagore (Fireflies, 1928)
CFLAGS ?= -O2
FFLAGS ?= -O2
all: zdrot_test
zdrot_test: zdrot.o zdrot_test.o
zdrot.o: zdrot.f
gfortran -c $(FFLAGS) $< -o $@
zdrot_test.o: zdrot_test.c
$(CC) -c $(CFLAGS) $< -o $@
.PHONY: clean
clean:
$(RM) zdrot_test.o zdrot.o zdrot_test
SUBROUTINE ZDROT( N, CX, INCX, CY, INCY, C, S )
*
* .. Scalar Arguments ..
INTEGERINCX, INCY, N
DOUBLE PRECISION C, S
* ..
* .. Array Arguments ..
COMPLEX*16 CX( * ), CY( * )
* ..
*
* Purpose
* ===
*
* Applies a plane rotation, where the cos and sin (c and s) are real
* and the vectors cx and cy are complex.
* jack dongarra, linpack, 3/11/78.
*
* Arguments
* ==
*
* N(input) INTEGER
* On entry, N specifies the order of the vectors cx and cy.
* N must be at least zero.
* Unchanged on exit.
*
* CX (input) COMPLEX*16 array, dimension at least
* ( 1 + ( N - 1 )*abs( INCX ) ).
* Before entry, the incremented array CX must contain the n
* element vector cx. On exit, CX is overwritten by the updated
* vector cx.
*
* INCX (input) INTEGER
* On entry, INCX specifies the increment for the elements of
* CX. INCX must not be zero.
* Unchanged on exit.
*
* CY (input) COMPLEX*16 array, dimension at least
* ( 1 + ( N - 1 )*abs( INCY ) ).
* Before entry, the incremented array CY must contain the n
* element vector cy. On exit, CY is overwritten by the updated
* vector cy.
*
* INCY (input) INTEGER
* On entry, INCY specifies the increment for the elements of
* CY. INCY must not be zero.
* Unchanged on exit.
*
* C(input) DOUBLE PRECISION
* On entry, C specifies the cosine, cos.
* Unchanged on exit.
*
* S(input) DOUBLE PRECISION
* On entry, S specifies the sine, sin.
* Unchanged on exit.
*
* =
*
* .. Local Scalars ..
INTEGERI, IX, IY
COMPLEX*16 CTEMP
* ..
* .. Executable Statements ..
*
IF( N.LE.0 )
$ RETURN
IF( INCX.EQ.1 .AND. INCY.EQ.1 )
$ GO TO 20
*
*code for unequal increments or equal increments not equal
* to 1
*
IX = 1
IY = 1
IF( INCX.LT.0 )
$ IX = ( -N+1 )*INCX + 1
IF( INCY.LT.0 )
$ IY = ( -N+1 )*INCY + 1
DO 10 I = 1, N
CTEMP = C*CX( IX ) + S*CY( IY )
CY( IY ) = C*CY( IY ) - S*CX( IX )
CX( IX ) = CTEMP
IX = IX + INCX
IY = IY + INCY
10 CONTINUE
RETURN
*
*code for both increments equal to 1
*
20 CONTINUE
DO 30 I = 1, N
CTEMP = C*CX( I ) + S*CY( I )
CY( I ) = C*CY( I ) - S*CX( I )
CX( I ) = CTEMP
30 CONTINUE
RETURN
END
#include
#include
typedef struct _dcomplex {
double real;
double imag;
} dcomplex;
int
zdrot_(int *N, dcomplex *CX, int *INCX, dcomplex *CY,int *INCY, double *C, double *S);
int
main(void)
{
int i;
int n = 5;
dcomplex cx[] = {{1.0, 1.0}, {2.0, 2.0}, {3.0, 3.0}, {4.0, 4.0}, {5.0, 5.0}, {1.0, 1.0}, {2.0, 2.0}, {3.0, 3.0}, {4.0, 4.0}};
int incx = 2;
dcomplex cy[] = {{-5.0, 5.0}, {0.0, 0.0}, {-4.0, 4.0}, {0.0, 0.0}, {-3.0, 3.0}, {0.0, 0.0}, {-2.0, 2.0}, {0.0,
Bug#569436: blas: zgesvd seems to give incorrect results
Hi, For the record, thanks to the GCC compile farm, I determined that this bug has been fixed in gcc trunk by http://gcc.gnu.org/viewcvs?view=revision&revision=145494 Unfortunately this is a merge from a branch (alias-improvements) which is not mirrored by git, so I had not been able to run git-bisect on it to find the atomic commit. And since this portion of code has been heavily modified, I doubt that it could be backported to gcc 4.4. I do not know what can be done now. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#571572: Bug#569436: blas: zgesvd seems to give incorrect results
(Also CCing #571572) Dear Denis, On Sat, Feb 27, 2010 at 05:44:45PM +0100, Denis Barbier wrote: > Hi, > > I played with the example provided by Kumar Appaiah, and narrowed the > problem down to zdrot; after copying zdrot.f into the same directory > as zgesvd_ex.f: > $ gfortran -O2 -c zgesvd_ex.f > $ gfortran -O2 -c zdrot.f > $ gfortran -o zgesvd_ex zgesvd_ex.o zdrot.o -llapack > $ ./zgesvd_ex > gives the expected result (with libblas3gf 1.2-4), but > $ gfortran -O2 -ftree-vectorize -c zdrot.f > $ gfortran -o zgesvd_ex zgesvd_ex.o zdrot.o -llapack > $ ./zgesvd_ex > gives the wrong result. > This looks like a bug in the gcc vectorizer, and it cannot be > reproduced with gcc 4.5 from experimental. This was fantastic analysis. I actually would like to know how you zeroed in onto zdrot to find the problem. I shall now try to play around with zdrot to see if I can create a test case which reproduces the bug, so that I can file a bug report with GCC. Thanks so much! Kumar -- In this playhouse of infinite forms I have had my play, and here have I caught sight of him that is formless. - Rabindranath Tagore (Gitanjali, 1912) signature.asc Description: Digital signature
Bug#571572: Bug#569436: blas: zgesvd seems to give incorrect results
On 2010/2/27 Kumar Appaiah wrote: > (Also CCing #571572) > > Dear Denis, > > On Sat, Feb 27, 2010 at 05:44:45PM +0100, Denis Barbier wrote: >> Hi, >> >> I played with the example provided by Kumar Appaiah, and narrowed the >> problem down to zdrot; after copying zdrot.f into the same directory >> as zgesvd_ex.f: >> $ gfortran -O2 -c zgesvd_ex.f >> $ gfortran -O2 -c zdrot.f >> $ gfortran -o zgesvd_ex zgesvd_ex.o zdrot.o -llapack >> $ ./zgesvd_ex >> gives the expected result (with libblas3gf 1.2-4), but >> $ gfortran -O2 -ftree-vectorize -c zdrot.f >> $ gfortran -o zgesvd_ex zgesvd_ex.o zdrot.o -llapack >> $ ./zgesvd_ex >> gives the wrong result. >> This looks like a bug in the gcc vectorizer, and it cannot be >> reproduced with gcc 4.5 from experimental. > > This was fantastic analysis. I actually would like to know how you > zeroed in onto zdrot to find the problem. Hi, I used brute force ;) libblas3gf 1.2-4 is installed on my system, object files from libblas3gf 1.2-3 have been unpacked into dir1, half files are moved into dir2. then I compiled gfortran zgesvd_ex.o dir1/*.o -llapack and by dichotomy found which object file is causing trouble. > I shall now try to play around with zdrot to see if I can create a > test case which reproduces the bug, so that I can file a bug report > with GCC. I am afraid that this is not easy, and anyway GCC folks will discard your bugreport since this bug has been fixed in 4.5. But I am very interested to know the exact reason, and if there is a way to prevent this bug by modifying source files. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#571572: Bug#569436: blas: zgesvd seems to give incorrect results
Dear Denis,
On Wed, Mar 03, 2010 at 11:41:50AM +0100, Denis Barbier wrote:
> Hi,
>
> For the record, thanks to the GCC compile farm, I determined that this
> bug has been fixed in gcc trunk by
>http://gcc.gnu.org/viewcvs?view=revision&revision=145494
> Unfortunately this is a merge from a branch (alias-improvements) which
> is not mirrored by git, so I had not been able to run git-bisect on it
> to find the atomic commit. And since this portion of code has been
> heavily modified, I doubt that it could be backported to gcc 4.4. I
> do not know what can be done now.
I think we can still file a bug report. Could you please test the
attach test case, and let me know if it is reproducible? For me,
here's what I do:
[~/Kumar/Programming/Blas_test] gcc -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.3-2'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--enable-multiarch --enable-linker-build-id --with-system-zlib
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc
--with-arch-32=i486 --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.4.3 (Debian 4.4.3-2)
$ make clean
rm -f zdrot_test.o zdrot.o zdrot_test
$ make
cc -c -O2 zdrot_test.c -o zdrot_test.o
gfortran -c -O2 -ftree-vectorize zdrot.f -o zdrot.o
cc zdrot_test.o zdrot.o -o zdrot_test
$ ./zdrot_test |tee 1
x: {(-0.8568, -0.), (-0.3505, -0.2082), (0.1505, 0.6113)}
y: {(0.4017, -0.), (-0.2403, -0.2102), (0.6074, 0.6064)}
$ make clean
rm -f zdrot_test.o zdrot.o zdrot_test
$ make FFLAGS=-O2
cc -c -O2 zdrot_test.c -o zdrot_test.o
gfortran -c -O2 zdrot.f -o zdrot.o
cc zdrot_test.o zdrot.o -o zdrot_test
$ ./zdrot_test |tee 2
x: {(-0.8568, -0.), (-0.3505, 0.1285), (0.1505, 0.3224)}
y: {(0.4017, -0.), (-0.2403, -0.2102), (0.6074, 0.6064)}
$ diff 1 2
1c1
< x: {(-0.8568, -0.), (-0.3505, -0.2082), (0.1505, 0.6113)}
---
> x: {(-0.8568, -0.), (-0.3505, 0.1285), (0.1505, 0.3224)}
$
I have attached the relevant files.
Thank you.
Kumar
--
To the guests that must go, bid God's speed and brush away all traces
of their steps.
- Rabindranath Tagore (The Gardener, 1915)
CFLAGS ?= -O2
FFLAGS ?= -O2 -ftree-vectorize
LFLAGS ?= -O3
FC = gfortran
all: zdrot_test
zdrot_test: zdrot.o zdrot_test.o
zdrot.o: zdrot.f
$(FC) -c $(FFLAGS) $< -o $@
zdrot_test.o: zdrot_test.c
$(CC) -c $(CFLAGS) $< -o $@
.PHONY: clean
clean:
$(RM) zdrot_test.o zdrot.o zdrot_test
#include
#include
typedef struct _dcomplex {
double real;
double imag;
} dcomplex;
int
zdrot_(int *N, dcomplex *CX, int *INCX, dcomplex *CY,int *INCY, double *C, double *S);
void
dump_array(int n, int incx, const dcomplex *cx, const char *label)
{
int i;
printf("%s: {", label);
for (i = 0; i < n - 1; ++i) {
printf("(%.4f, %.4f), ", cx[incx * i].real, cx[incx * i].imag);
}
printf("(%.4f, %.4f)}\n", cx[incx * (n - 1)].real, cx[incx * (n - 1)].imag);
}
int
main(void)
{
int i, n, incx, incy;
double c, s;
/* int n = 5; */
/* dcomplex cx[] = {{1.0, 1.0}, {2.0, 2.0}, {3.0, 3.0}, {4.0, 4.0}, {5.0, 5.0}, {1.0, 1.0}, {2.0, 2.0}, {3.0, 3.0}, {4.0, 4.0}}; */
/* int incx = 2; */
/* dcomplex cy[] = {{-5.0, 5.0}, {0.0, 0.0}, {-4.0, 4.0}, {0.0, 0.0}, {-3.0, 3.0}, {0.0, 0.0}, {-2.0, 2.0}, {0.0, 0.0}, {-1.0, 1.0}}; */
/* int incy = 2; */
dcomplex cx[] = {{-0.85979604472439053,-2.7649680642690493e-18},
{-0.34870067583684999,0.13008763797653625},
{0.1458460044809155,0.31774950758397147}
};
dcomplex cy[] = {{0.39513973218816306,-1.6608257098635789e-17},
{-0.24300238986826755,-0.20921321526463676},
{0.60854527713236894,0.60886526161631016}
};
n = 3;
incx = incy = 1;
c = 0.7081162455026;
s = 0.007640412223039174;
zdrot_(&n, cx, &incx, cy, &incy, &c, &s);
dump_array(n, incx, cx, "x");
dump_array(n, incy, cy, "y");
return 0;
}
SUBROUTINE ZDROT( N, CX, INCX, CY, INCY, C, S )
*
* .. Scalar Arguments ..
INTEGERINCX, INCY, N
DOUBLE PRECISION C, S
* ..
* .. Array Arguments ..
COMPLEX*16 CX( * ), CY( * )
* ..
*
* Purpose
* ===
*
* Applies a plane rotation, where the cos and sin (c and s) are real
* and the vectors cx and cy are complex.
* jack dongarra, linpack, 3/11/78.
*
* Arguments
* ==
*
* N(input) INTEGER
* On entry, N specifies the order of the vectors cx and cy.
* N must be at least zero.
* Unchanged on exit.
*
* CX (input) COMPLEX*16 array, dimension at least
* ( 1 + ( N - 1 )*abs( INCX ) ).
* Before entry, the incremented array CX must contain th
Bug#571572: Bug#569436: blas: zgesvd seems to give incorrect results
clone 571572 -1 reassign -1 gcc-4.4 4.4.3-3 retitle -1 errnoenous code generated with -ftree-vectorize forwarded -1 http://gcc.gnu.org/PR43251 block 571572 by -1 thanks Dear Daniel, On Wed, Mar 03, 2010 at 09:11:29PM +0100, Denis Barbier wrote: > On 2010/3/3 Kumar Appaiah wrote: > > Dear Denis, > > > > On Wed, Mar 03, 2010 at 11:41:50AM +0100, Denis Barbier wrote: > >> Hi, > >> > >> For the record, thanks to the GCC compile farm, I determined that this > >> bug has been fixed in gcc trunk by > >> http://gcc.gnu.org/viewcvs?view=revision&revision=145494 > >> Unfortunately this is a merge from a branch (alias-improvements) which > >> is not mirrored by git, so I had not been able to run git-bisect on it > >> to find the atomic commit. And since this portion of code has been > >> heavily modified, I doubt that it could be backported to gcc 4.4. I > >> do not know what can be done now. > > > > I think we can still file a bug report. Could you please test the > > attach test case, and let me know if it is reproducible? > [...] > > Waow, you did it, congratulations. I can indeed reproduce this bug > with your small testcase. Wonderful! I've reported the bug to upstream gcc, and have created a new bug against the Debian gcc and blocked this bug by it. Hope this helps. Thanks for pointing me in the right direction. Kumar -- If you shed tears when you miss the sun, you also miss the stars. - Rabindranath Tagore (Stray Birds, 1916) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#569436: Bug#571572: Bug#569436: blas: zgesvd seems to give incorrect results
On 2010/3/3 Kumar Appaiah wrote: > Dear Denis, > > On Wed, Mar 03, 2010 at 11:41:50AM +0100, Denis Barbier wrote: >> Hi, >> >> For the record, thanks to the GCC compile farm, I determined that this >> bug has been fixed in gcc trunk by >> http://gcc.gnu.org/viewcvs?view=revision&revision=145494 >> Unfortunately this is a merge from a branch (alias-improvements) which >> is not mirrored by git, so I had not been able to run git-bisect on it >> to find the atomic commit. And since this portion of code has been >> heavily modified, I doubt that it could be backported to gcc 4.4. I >> do not know what can be done now. > > I think we can still file a bug report. Could you please test the > attach test case, and let me know if it is reproducible? [...] Waow, you did it, congratulations. I can indeed reproduce this bug with your small testcase. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#569436: Bug#571572: Bug#569436: blas: zgesvd seems to give incorrect results
> > Waow, you did it, congratulations. I can indeed reproduce this bug > > with your small testcase. > > Wonderful! I've reported the bug to upstream gcc, and have created a > new bug against the Debian gcc and blocked this bug by it. > > Hope this helps. Thanks for pointing me in the right direction. Impressive. I have been following your investigations. Well done for finding all this. Sylvestre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
