Bug in x64 C++ compiler (optimizer) by Bert Rodiers

We are having crashes in LAPACK and BLAS code (Fortran code automatically converted to C++) when we compile for 64 bit in release mode. When using 64-bit Debug mode, 32-bit release mode or 32-bit debug mode there isn't any problem.

We have downsized the problem to the minimal code that still crashed. The code below allows to reproduce the problem

// VSTest.cpp : Defines the entry point for the console application.
//

#include "stdafx.h"
#include <ctype.h>
#include <math.h>
#include <string.h>

//#define NO_OPTIMIZATIONS 1

#ifdef NO_OPTIMIZATIONS
#if defined (_M_X64)
#pragma optimize( "", off )
#endif
#endif

void dtrmv(const long &n, double *a, const long &lda, double x[])
{
#define A(I_,J_) (*(a+(I_)*(lda)+(J_)))
    double temp;

    //        Form x := A'*x.

    for( int j = n, j_ = j - 1; j >= 1; j--, j_-- ) {
        temp = x[j_];
        temp = temp*A(j_,j_);
        for( int i = j - 1, i_ = i - 1; i >= 1; i--, i_-- ) {
            temp = temp + A(j_,i_)*x[i_];
        }
        x[j_] = temp;
    }

#undef A
}

#ifdef NO_OPTIMIZATIONS
#if defined (_M_X64)
#pragma optimize( "", on )
#endif
#endif


int _tmain(int argc, _TCHAR* argv[])
{

    double* t = new double[64*65];
    memset(t,0,64*65*sizeof(double));

#define T(I_,J_) (*(t+(I_)*(65)+(J_)))

    dtrmv( 5, t, 65, &T(31, 0));

    delete t;
    return 0;
}


The crash is at this line of code while executing the code:
temp = temp + A(j_,i_)*x[i_];
and on this instruction:000000014000112A mulsd xmm0,mmword ptr [rcx+8]

[rcx+8] should be the memory address of A(_j,_i), but the memory that is being accessed is quite before the start of the "matrix" A.

When you step through the disassembly, systematically the wrong address in the memory space is being accessed, both for A(j_,i_) and for x[i_].

When creating this example we didn't change the default settings in the Visual Studio project, except changing the platform (to X64) and the configuration (to Release).
We have inspected the C++ code and believe it is correct.

When the following line is uncommented:
//#define NO_OPTIMIZATIONS 1
the code works. Hence if we disable the optimizations we have no problem.
However it is rather painful having to disable optimizations for the most performance critical code.