Dave Goodell <good...@mcs.anl.gov> wrote:
> Valgrind's "--track-origins=yes" option is usually helpful for
figuring out where the uninitialized values came from.
Good suggestion - that did eventually lead to the solution.
The code always had two vector types (_m128i and _m128), and there are
still two types (_m64 and _m128), but whereas previously the two types
were the same size and a single vsz variable sufficed in the relevant
mpi send/receive functions, two such variables are now needed. The end
result was that an array was being half filled by MPI send/recv. This
bit of code was only exercised in this one program, which is why it
didn't show up previously in any of the other programs in this package,
or in any of the other run modes. On top of that there were a large
number of valgrind messages resulting from MPI_send operations passing
the full length of the allocated buffer instead of just the part used.
Those don't seem to have been causing any run time problems, but they
added to the noise when trying to debug this.
The strangeness with seemingly uninitialized vector following a zeroing
operation turned out to be a red herring. This:
register __m128 xEv;
fprintf(stderr,"DEBUG xEV is %lld\n",xEv);fflush(stderr);
just doesn't work, probably because xEv is 16 bytes but lld is 8. Using
an alternative method eliminated that problem:
typedef union {
__m128 vf;
float f4[4];
} __uni16;
#define EMM_FLT4(a) (((__uni16)(a)).f4)
fprintf(stderr,"DEBUG xEV values %f %f %f
%f\n",EMM_FLT4(xEv)[0],EMM_FLT4(xEv)[1],EMM_FLT4(xEv)[2],EMM_FLT4(xEv)[3]);fflush(stderr);
Thanks!
David Mathog
mat...@caltech.edu
Manager, Sequence Analysis Facility, Biology Division, Caltech
