Unitialized issue in cblas_dsyrk

[EAnde4]

I have created a very small test program that illustrates an an issue in syrk. In fact when I run valgrind on my program I get.

==44033==

==44033== Conditional jump or move depends on uninitialised value(s)
==44033==    at 0x401CFD: main (testsyrk.c:40)
==44033==
Check 990
==44033==
==44033== HEAP SUMMARY:
==44033==     in use at exit: 39,184 bytes in 4 blocks
==44033==   total heap usage: 4 allocs, 0 frees, 39,184 bytes allocated

My program is so simple and I will claim the uninitialised value comes from cblas_dsyrk.

The follow instructions reproduce the issue:

icc -g -o testsyrk testsyrk.c -I$MKLROOT/include  -Wl,--start-group $MKLROOT/lib/intel64/libmkl_intel_lp64.a $MKLROOT/lib/intel64/libmkl_core.a $MKLROOT/lib/intel64/libmkl_sequential.a -Wl,--end-group -lpthread -lm

valgrind ./testsyrk 

I use the latest Intel 15.0.1.

Here is my program

#include <stdio.h>
#include <stdlib.h>

#include "mkl_cblas.h"
#include "mkl_lapack.h"

int main()
{
  double *source,*target;
  int    i,j,
         z=0,
         d=44,w=14;

  source = calloc(d*w,sizeof(double));
  target = calloc(d*d,sizeof(double));

  for(j=0; j<w; ++j)
    for(i=0; i<d; ++i)
      source[d*j+i] = 1.0;

  for(j=0; j<d; ++j)
    for(i=0; i<=j; ++i)
      if ( target[j*d+i]>0.0 )
        z += 1;
 
  cblas_dsyrk(CblasColMajor,
              CblasUpper,
              CblasNoTrans,
              d,w,
              1.0,source,d,
              0.0,target,d);

  for(j=0; j<d; ++j)
    for(i=0; i<=j; ++i)
    {
      #if 0
      fprintf(stderr,"%d %d\n",i,j);
      #endif

      if ( target[j*d+i]>0.0 )
        z += 1;
    }
 
  printf("Check %d\n",z);

  return ( 0 );
}

[Gennady_F_Intel]

mosek,

before we will check the problem on our side - a couple of questions:

Have you seen the run-time problem with cblas_dsyrk?  

and the second one -- have you tried Intel(R) Inspector tool for check this problem?  

Personally, I met several cases when valgrind reported the false positives....

--Gennady

[EAnde4]

I do not own Inspector for Linux.

No. Run time does not seem to be affected. But as you know that might be pure luck. We suspect you add an unitialized (lucky) zero to the output. In any case my customers complains if they find valgrind issues with our software. They simply loose confidence in it. 

Otherwise I agree valgrind is not perfect but that is usually when we use the optimized memset etc. from Intel C.

So I do

WW' = U

of course where U has 44 rows and W has 14 columns. Using printf+valgrind  it seems the error is at row 0 position 30. Maybe that is a border case for the internal partitioning.

Btw I spend a whole day working on locating this and then creating the small example. Maybe this tells a bit about the importance about this for us.

[mecej4]

I concur with Gennady's comment that Valgrind produces lots of false positives w.r.t. uninitialized values when applied to programs compiled with the Intel compilers.

There may be a problem with MKL-CBLAS-dsyrk in your application, but the example code does not display any problem other than the shortcoming of Valgrind.

I tested the program by (i) dumping the "target" matrix to a file using fwrite, (ii) recompiling the test program with gcc and libgslcblas, and (iii) comparing the dump files from (i) and (ii). The files were identical.

I also tested the same program (compiled with icc -mkl -g) with the Intel Inspector. Other than a small memory leak (variable allocated within MKL but not freed), there were no errors -- in particular, no uninitialized variables were detected. A similar message was given by Inspector when applied to the Gcc-compiled version.

[EAnde4]

I agree it produces the correct result. But I still wish valgrind would not complain about it.

I guess I have more faith or less experience in valgrind than you guys.

[mecej4]

I wish that Valgrind would work nicely with programs built with the Intel compilers, too. Are you aware that Valgrind has a provision for "suppresion list"s? 

With complicated projects I sometimes use a different compiler to catch program errors and switch back to Intel for production runs.

[EAnde4]

The thing that make suspicious is that I have TONS of MKL call with many different matrix sizes. But this is the only one where valgrind complains.

My exprience if your run valgrind on code compiled with -g options you get less false positives.

[mecej4]

mosekmosek.com wrote:
My exprience if your run valgrind on code compiled with -g options you get less false positives.

Not only is this well-known but it is also understandable. Unfortunately, if the compiler optimization phase has bugs, this property of Valgrind makes it less useful for pinpointing those bugs. In such circumstances I have found myself wondering whether I am debugging my code, the compiler, Valgrind or the MKL library!