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