Bug in zgemm on AMD

[andreasnoack]

On a AMD FX(tm)-8320 Eight-Core Processor machine running Windows and with OpenBLAS complied with 64 bit integer support the following program

program test

     complex*16 :: a(4,4), b(4,4), c(4,4)

     a(:,:) = (1.0d0, 1.0d0)
     b(:,:) = 1.0d0

     call zgemm('N', 'N', 4_8, 4_8, 4_8, (1.0d0, 0.0d0), a, 4_8, b, 4_8, (0.0d0, 0.0d0), c, 4_8)

    write(*,*) c

 end program

gives the wrong answer

(  0.0000000000000000     ,  8.0000000000000000     ) (  0.0000000000000000
 ,  8.0000000000000000     ) (  0.0000000000000000     ,  8.0000000000000000
 ) (  0.0000000000000000     ,  8.0000000000000000     ) (  0.0000000000000000
   ,  8.0000000000000000     ) (  0.0000000000000000     ,  8.0000000000000000
   ) (  0.0000000000000000     ,  8.0000000000000000     ) (  0.0000000000000000
     ,  8.0000000000000000     ) (  0.0000000000000000     ,  8.0000000000000000
     ) (  0.0000000000000000     ,  8.0000000000000000     ) (  0.00000000000000
00     ,  8.0000000000000000     ) (  0.0000000000000000     ,  8.00000000000000
00     ) (  0.0000000000000000     ,  8.0000000000000000     ) (  0.000000000000
0000     ,  8.0000000000000000     ) (  0.0000000000000000     ,  8.000000000000
0000     ) (  0.0000000000000000     ,  8.0000000000000000     )

[andreasnoack]

The problem is also present for cgemm.

[wernsaar]

On 03.06.2014 20:20, Andreas Noack Jensen wrote:

On a AMD FX(tm)-8320 Eight-Core Processor machine running Windows and with OpenBLAS complied with 64 bit integer support the following program

program test

      complex*16 :: a(4,4), b(4,4), c(4,4)

      a(:,:) = (1.0d0, 1.0d0)
      b(:,:) = 1.0d0

      call zgemm('N', 'N', 4_8, 4_8, 4_8, (1.0d0, 0.0d0), a, 4_8, b, 4_8, (0.0d0, 0.0d0), c, 4_8)

      write(*,*) c

  end program

gives the wrong answer

(  0.0000000000000000     ,  8.0000000000000000     ) (  0.0000000000000000
  ,  8.0000000000000000     ) (  0.0000000000000000     ,  8.0000000000000000
  ) (  0.0000000000000000     ,  8.0000000000000000     ) (  0.0000000000000000
    ,  8.0000000000000000     ) (  0.0000000000000000     ,  8.0000000000000000
    ) (  0.0000000000000000     ,  8.0000000000000000     ) (  0.0000000000000000
      ,  8.0000000000000000     ) (  0.0000000000000000     ,  8.0000000000000000
      ) (  0.0000000000000000     ,  8.0000000000000000     ) (  0.00000000000000
00     ,  8.0000000000000000     ) (  0.0000000000000000     ,  8.00000000000000
00     ) (  0.0000000000000000     ,  8.0000000000000000     ) (  0.000000000000
0000     ,  8.0000000000000000     ) (  0.0000000000000000     ,  8.000000000000
0000     ) (  0.0000000000000000     ,  8.0000000000000000     )

---

Reply to this email directly or view it on GitHub:
#380
Hi,

I cannot reproduce this error.
Please give me more information.

Is this a 32bit or 64bit build, what is the TARGET, do you use threading?

Regards

Werner

[andreasnoack]

We have only seen it on the reported architecture. It is a 64 bit build and the bug is there both with and without threading. @tkelman Can you say more about the TARGET?

[tkelman]

I think TARGET is empty. The set of Makefile flags, as best as I can reconstruct them, are:

FFLAGS=-O2 USE_THREAD=1 NUM_THREADS=16 NO_AFFINITY=1 DYNAMIC_ARCH=1 INTERFACE64=1 BINARY=64

[wernsaar]

On 04.06.2014 14:50, Tony Kelman wrote:

I think TARGET is empty. The set of Makefile flags, as best as I can reconstruct them, are:

FFLAGS=-O2 USE_THREAD=1 GEMM_MULTITHREADING_THRESHOLD=50 NUM_THREADS=16 NO_AFFINITY=1 DYNAMIC_ARCH=1 INTERFACE64=1 BINARY=64

---

Reply to this email directly or view it on GitHub:
#380 (comment)
Hi,

could you please compile with the following comand line:

FFLAGS=-O2 USE_THREAD=1 GEMM_MULTITHREADING_THRESHOLD=50 NUM_THREADS=16 NO_AFFINITY=1 TARGET=PILEDRIVER INTERFACE64=1 BINARY=64

Which C- and Fortran compiler do you use?

Regards

Werner

[wernsaar]

On 04.06.2014 14:50, Tony Kelman wrote:

I think TARGET is empty. The set of Makefile flags, as best as I can reconstruct them, are:

FFLAGS=-O2 USE_THREAD=1 GEMM_MULTITHREADING_THRESHOLD=50 NUM_THREADS=16 NO_AFFINITY=1 DYNAMIC_ARCH=1 INTERFACE64=1 BINARY=64

---

Reply to this email directly or view it on GitHub:
#380 (comment)
Hi,

I simply cannot reproduce the error.
I now published a binary package for windows on sourceforge.
Please download
http://sourceforge.net/projects/openblas/files/v0.2.9-rc2-lapacktest/openblas-v0.2.9-rc2-lapack-piledriver_win64bit_int64.tar.gz

The file Makefile.rule is included.
In the directory ftest, you can find the fortran test.

Best regards

Werner

[tkelman]

I used GCC and Gfortran 4.8.2, MinGW cross-compiled either from Linux (Julia binaries) or Cygwin (my build of up-to-date develop branch) to compile OpenBLAS.

The user who's seeing the issue was compiling the test program with

$ gfortran --version
GNU Fortran (tdm64-2) 4.8.1

[wernsaar]

On 04.06.2014 16:25, Tony Kelman wrote:

I used GCC and Gfortran 4.8.2, MinGW cross-compiled either from Linux (Julia binaries) or Cygwin (my build of up-to-date develop branch) to compile OpenBLAS.

The user who's seeing the issue was compiling the test program with

$ gfortran --version
GNU Fortran (tdm64-2) 4.8.1

---

Reply to this email directly or view it on GitHub:
#380 (comment)
Hi,

please try the binary, that I have now published at sourceforge.net.
http://sourceforge.net/projects/openblas/files/v0.2.9-rc2-lapacktest/openblas-v0.2.9-rc2-lapack-piledriver_win64bit_int64.tar.gz

and report the result.
I don't find a problem in the blas library, perhaps this could be
another problem.

Best regards

Werner

[tkelman]

cc @jasax

[ViralBShah]

@wernsaar Which Fortran compiler and what version do you use?

[wernsaar]

On 05.06.2014 19:48, Viral B. Shah wrote:

@wernsaar Which Fortran compiler and what version do you use?

---

Reply to this email directly or view it on GitHub:
#380 (comment)
Hi,

I built openblas for windows on our Ubuntu machine with mingw64.
But please wait a short time. Xianyi wrote me, that he found a bug, when
building
the dll on windows. He will provide a fix soon.

Best regards

Werner

[ViralBShah]

Best to reopen the issue.