Created attachment 64056 [details] full valgrind output Version: 3.7 SVN (using Devel) OS: OS X valgrind is terminating upon encountering an unrecognized instruction. When run standalone without valgrind, my program executes normally. The unrecognized instruction is actually encountered inside of an executing OpenCL kernel (executing on my CPU). This makes it very difficult to identify an instruction associated with it. I would guess it is some extended numerical operation since my kernel is just a bunch of math calculations. If I comment out the clEnqueueNDRangeKernel() call, valgrind executes without problem. This means if the processor does not execute the kernel code, the illegal instruction is not encountered. The computer is 2010 12-core Mac Pro (Intel Westmere). I am using Apple's OpenCL library/API and no specified compiler settings other than default. $ uname -a Darwin d.host.edu 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun 7 16:32:41 PDT 2011; root:xnu-1504.15.3~1/RELEASE_X86_64 x86_64 Reproducible: Always Steps to Reproduce: I'm hoping the instruction code is enough to work with here, because isolating the instruction to a line of OpenCL code is beyond what I know how to do. Expected Results: Should not identify the subject instruction as illegal.
That's ROUNDSS and should be supported by the current code - are you sure you're using the latest SVN code?
(In reply to comment #1) > That's ROUNDSS and should be supported by the current code - are you sure > you're using the latest SVN code? Yes I'm sure. Here is my svn revision: r12062 | florian | 2011-09-28 10:43:44 -0700 (Wed, 28 Sep 2011) | 2 lines I'm not able to run the release 3.6.1 valgrind due to a XCode 4.0 bug that has been addressed in later commits. I have some round(float) and floor(float) calls in my OpenCL kernel, these likely generate the offending instructions.
I think I see the problem - you seem to be asking for rounding mode 9 with that instruction (the 0x9 in the instruction is the rounding mode if I've decoded it right) but bit 4 of the rounding mode is reserved according to my manuals and valgrind objects if any of bits 4-7 are set in the rounding mode.
Ah no, it's bit 3 you have set, which means you want precise exceptions, but valgrind is rejecting that, probably because it can't do precise exceptions.
Created attachment 64076 [details] Patch to ignore the precision bit Actually setting that bit is asking for inexact exceptions, which shouldn't be a problem... Try this patch, which should make it ignore the precision bit in the rounding mode.
(In reply to comment #5) > Created an attachment (id=64076) [details] > Patch to ignore the precision bit > > Actually setting that bit is asking for inexact exceptions, which shouldn't be > a problem... > > Try this patch, which should make it ignore the precision bit in the rounding > mode. Cool. I'll give it a shot in about two hours and let you know.
The patch as provided by Tom resolved the issue. valgrind does not report the instruction as invalid. Thank you thank you. (and thankfully no new invalid instructions were detected either) I speculate that this uncommon instruction is flushed out now because Apple's OpenCL implementation is almost certainly using their LLVM compiler when building for the CPU.
Committed as VEX r2211.
*** Bug 273729 has been marked as a duplicate of this bug. ***