Bug 227980 - unhandled instruction bytes: 0x66 0xF 0x38 0x3F 0xC1 0x39
Summary: unhandled instruction bytes: 0x66 0xF 0x38 0x3F 0xC1 0x39
Status: RESOLVED FIXED
Alias: None
Product: valgrind
Classification: Developer tools
Component: vex (show other bugs)
Version: 3.5.0
Platform: Fedora RPMs Linux
: NOR normal
Target Milestone: ---
Assignee: Julian Seward
URL:
Keywords:
Depends on:
Blocks: 253451
  Show dependency treegraph
 
Reported: 2010-02-21 22:31 UTC by Brian Bulkowski
Modified: 2011-08-23 15:11 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Brian Bulkowski 2010-02-21 22:31:48 UTC
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.
Comment 1 Julian Seward 2010-02-21 23:20:07 UTC
   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?
Comment 2 Brian Bulkowski 2010-02-21 23:31:36 UTC
(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.
Comment 3 Tom Hughes 2011-08-23 15:11:11 UTC
Support for this instruction was added in VEX r1976.