| Summary: | unhandled instruction bytes: 0x66 0xF 0x38 0x3F 0xC1 0x39 | ||
|---|---|---|---|
| Product: | [Developer tools] valgrind | Reporter: | Brian Bulkowski <brian> |
| Component: | vex | Assignee: | Julian Seward <jseward> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | tom |
| Priority: | NOR | ||
| Version: | 3.5.0 | ||
| Target Milestone: | --- | ||
| Platform: | Fedora RPMs | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Bug Depends on: | |||
| Bug Blocks: | 253451 | ||
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. |
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.