- Marquer comme nouveau
- Marquer
- S'abonner
- Sourdine
- S'abonner au fil RSS
- Surligner
- Imprimer
- Signaler un contenu inapproprié
I am using MKL 10.1.2.024 under Linux on a x86_64 machine.
There appears to be a bug in the MKL implementation of ZGEMM that computes complex(inf, 0) * complex(x, y) to be complex(nan, nan) instead of complex(inf, inf).
The behavior is demonstrated in the attached example program: zgemm_bug_small.cc
which I compiled with: icpc zgemm_bug_small.cc -o zgemm_bug.exe -L$(MKL) -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -lmkl_intel_thread -lmkl_core -lguide -lpthread
Notice I used only the static versions of the libraries and hence had to repeat them in order to resolve link-time conflicts.
Running the example outputs:
[user@machine mkl_test]$ ./zgemm_bug.exe
A = {( 1, 1) ( 0, 0) ( 0, 0)}
B = {( inf, 0) ( 1, 1)
( 0, 0) ( 0, 0)
( 0, 0) ( 0, 0)}
A.B computed using ZGEMM:
C = {( nan, nan) ( 0, 2)}
A.B computed using ZDOTU:
C = {( inf, inf) ( 0, 2)}
Notice that the ZDOTU result is what I would expect and contrary to what ZGEMM returns.
There appears to be a bug in the MKL implementation of ZGEMM that computes complex(inf, 0) * complex(x, y) to be complex(nan, nan) instead of complex(inf, inf).
The behavior is demonstrated in the attached example program: zgemm_bug_small.cc
which I compiled with: icpc zgemm_bug_small.cc -o zgemm_bug.exe -L$(MKL) -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -lmkl_intel_thread -lmkl_core -lguide -lpthread
Notice I used only the static versions of the libraries and hence had to repeat them in order to resolve link-time conflicts.
Running the example outputs:
[user@machine mkl_test]$ ./zgemm_bug.exe
A = {( 1, 1) ( 0, 0) ( 0, 0)}
B = {( inf, 0) ( 1, 1)
( 0, 0) ( 0, 0)
( 0, 0) ( 0, 0)}
A.B computed using ZGEMM:
C = {( nan, nan) ( 0, 2)}
A.B computed using ZDOTU:
C = {( inf, inf) ( 0, 2)}
Notice that the ZDOTU result is what I would expect and contrary to what ZGEMM returns.
Lien copié
3 Réponses
- Marquer comme nouveau
- Marquer
- S'abonner
- Sourdine
- S'abonner au fil RSS
- Surligner
- Imprimer
- Signaler un contenu inapproprié
Well, the same output we have win32 with version 10.2.
A.B computed using ZGEMM:
C = {(-1.#IND, -1.#IND) ( 0, 2)}
A.B computed using ZDOTU:
C = {(1.#INF, 1.#INF) ( 0, 2)}
We will check the problem and let you know if any news.
Thanks for the report.
--Gennady
- Marquer comme nouveau
- Marquer
- S'abonner
- Sourdine
- S'abonner au fil RSS
- Surligner
- Imprimer
- Signaler un contenu inapproprié
Thank you, much appreciated.
- Marquer comme nouveau
- Marquer
- S'abonner
- Sourdine
- S'abonner au fil RSS
- Surligner
- Imprimer
- Signaler un contenu inapproprié
Quoting - darshan
I am using MKL 10.1.2.024 under Linux on a x86_64 machine.
There appears to be a bug in the MKL implementation of ZGEMM that computes complex(inf, 0) * complex(x, y) to be complex(nan, nan) instead of complex(inf, inf).
The behavior is demonstrated in the attached example program: zgemm_bug_small.cc
which I compiled with: icpc zgemm_bug_small.cc -o zgemm_bug.exe -L$(MKL) -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -lmkl_intel_thread -lmkl_core -lguide -lpthread
Notice I used only the static versions of the libraries and hence had to repeat them in order to resolve link-time conflicts.
Running the example outputs:
[user@machine mkl_test]$ ./zgemm_bug.exe
A = {( 1, 1) ( 0, 0) ( 0, 0)}
B = {( inf, 0) ( 1, 1)
( 0, 0) ( 0, 0)
( 0, 0) ( 0, 0)}
A.B computed using ZGEMM:
C = {( nan, nan) ( 0, 2)}
A.B computed using ZDOTU:
C = {( inf, inf) ( 0, 2)}
Notice that the ZDOTU result is what I would expect and contrary to what ZGEMM returns.
There appears to be a bug in the MKL implementation of ZGEMM that computes complex(inf, 0) * complex(x, y) to be complex(nan, nan) instead of complex(inf, inf).
The behavior is demonstrated in the attached example program: zgemm_bug_small.cc
which I compiled with: icpc zgemm_bug_small.cc -o zgemm_bug.exe -L$(MKL) -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -lmkl_intel_thread -lmkl_core -lguide -lpthread
Notice I used only the static versions of the libraries and hence had to repeat them in order to resolve link-time conflicts.
Running the example outputs:
[user@machine mkl_test]$ ./zgemm_bug.exe
A = {( 1, 1) ( 0, 0) ( 0, 0)}
B = {( inf, 0) ( 1, 1)
( 0, 0) ( 0, 0)
( 0, 0) ( 0, 0)}
A.B computed using ZGEMM:
C = {( nan, nan) ( 0, 2)}
A.B computed using ZDOTU:
C = {( inf, inf) ( 0, 2)}
Notice that the ZDOTU result is what I would expect and contrary to what ZGEMM returns.
Dear Customer,
Thanks for your report, this issue has been submitted to our internal development tracking database for futher investigation, we will inform you once a new update becomes available.
Here is a bug tracking number for your reference: 200083929.
Thanks,
Ying

Répondre
Options du sujet
- S'abonner au fil RSS
- Marquer le sujet comme nouveau
- Marquer le sujet comme lu
- Placer ce Sujet en tête de liste pour l'utilisateur actuel
- Marquer
- S'abonner
- Page imprimable