gcc (GCC) 4.4.3 20100127 (Red Hat 4.4.3-4) Thus, Fedora Core 12 (64-bit), up to date. Requires -O3 and -D_GNU_SOURCE to occur. Had never had this problem until I recently added -D_GNU_SOURCE. I am adding it only to gain access to the ffs() function call. I use -march=native and -msse4 (processor identifies as Intel Core 2 Duo) The C code Valgrind is fingering is highly benign, where // Figure out how many bytes you need int mt_rows = mt_sz / sizeof(msg_template); if (mt_rows <= 0) { I don't believe the problem is actually here, though, because this section of code is run through multiple times with the same parameter without error. I suspect the location reported by valgrind is incorrect. Let me know what other information I can provide. I love valgrind.
0: 66 0f 38 3f c1 pmaxud %xmm1,%xmm0 This "if (mt_rows <= 0)" appears in some loop that (presumably) gcc managed to vectorize. Right?
(In reply to comment #1) > 0: 66 0f 38 3f c1 pmaxud %xmm1,%xmm0 > > This "if (mt_rows <= 0)" appears in some loop that (presumably) > gcc managed to vectorize. Right? Perhaps. If so the loop vectorizer is getting very fancy, as these two lines are the first of a function, and this function is likely too long to inline - and crosses a library boundary. Could be, though, and would explain why other calls to the function (presumably non-vectorized) are succeeding. Is there something I could/should do to test this theory, like turn off loop vectorization, or is it just enough for you to know this opcode is not supported? If it's supported in a later version I'm happy to build from source / SVN.
Support for this instruction was added in VEX r1976.