melirius

Bug in OpenCL compiler

Discussion created by melirius on May 31, 2020
Latest reply on Jun 8, 2020 by melirius

Finally I made a minimal reproducing example of a bug in OpenCL compilers for Thaiti in Adrenalin Win10 x64 drivers (tested on two workstations with 19.12.2, 20.1.1 and 20.5.1 drivers with -O0 and -O5). Kernel is attached (it is a part of my realization of improved iterative Gauss-Seidel WDK-method for complex polynomial roots finding). As is, it gives wrong result for poly and its parts poly1 and poly2:

 

l=0, poly=0.0768369+0.00147968i, prod=13+6.62408e-17i, tau=-0.999259-0.0385005i
poly1=-8.84608e-18+1.99574i, poly2=0.0768369-1.99426i
{0,0.483322,0.966644,1.44997,1.93329,2.41661,2.89993,-2.89993,-2.41661,-1.93329,-1.44997,-0.966644,-0.483322}

Changing 1 to 2 in the loop upper limit miraculously gives the right result:

l=0, poly=-1.11022e-16+0i, prod=13+6.62408e-17i, tau=-0.999259-0.0385005i
poly1=0.997775+0.0192146i, poly2=-0.997775-0.0192146i
{0,0.483322,0.966644,1.44997,1.93329,2.41661,2.89993,-2.89993,-2.41661,-1.93329,-1.44997,-0.966644,-0.483322}

Another small changes in the code switch right and wrong results in a seemingly random way. For example, commenting out third line of output in printf here gives always right results, but when line of initial code

z[l] -= cdiv(poly, prod);

is added before printf, result starts to be consistently wrong even without printf.

On my old laptop with 15.200.1065.0 drivers this bug is absent.

dipak opencl 1.2 amd driver bug

Attachments

Outcomes