Showing results for 
Search instead for 
Did you mean: 

Archives Discussions

Journeyman III

OSX Lion 10.7.4 update killed my kernel ...

-- new drivers, apparently --

(This is on AMD only; it works fine with nVidia and Intel i7 and Xeon)

fails with "Error getting function data from server", but the good news is that there's much more info in the console log, including:

5/10/12 2:29:21.792 PM Both operands to a binary operator are not of the same type!

5/10/12 2:29:21.792 PM   %34 = fadd <4 x float> %33, i32 %32

5/10/12 2:29:21.792 PM Instruction does not dominate all uses!

5/10/12 2:29:21.792 PM   %34 = fadd <4 x float> %33, i32 %32

5/10/12 2:29:21.792 PM   store <4 x float> %34, <4 x float>* %Y, align 16

5/10/12 2:29:21.792 PM Broken module found, compilation aborted!

... however, that's at a lower level than what I have available to me before I send off the OpenCL-C to the compiler!

Any hints on how to track these down?  Is it the case that I have an IL representation that compiled under the old version but now fails?  OR, is the IL itself the product of a new bug?  How can I tell?....

Thanks for any ideas!

[ I know that AMD does not support Apple-supplied drivers; just looking for hints or clues! ]

... and, for what it's worth, if I go back to unvectorized code (which worked before the update) buildprogram hangs my whole Mac Pro, requiring hard power-off....

5 Replies

It looks like somewhere the code you are generating is trying to add a vector of floats to a integer value(The %32 and %34 mean its the 32nd and 34th operation that is not assigned to a variable, so maybe looking there will help). This is illegal in both LLVM and OpenCL C. This is a problem with Apple's implementation and you need to report the issue to them.

Thanks for your answer, Micah.

Yes, I did figure out that the one complaint is about trying to add an i32 to a float4.  Perhaps an automatic conversion previously performed by the old C->IL compiler fails in the new one, and I may be able to track it down in my (complex) kernel.  I don't know what it doesn't like about "store <4 x float> %34, <4 x float>* %Y, align 16", though I could go through and comment out lines that store float4s using pointers.  (Maybe it should be "align 128"....)

For now, I just need this to work, so, if I don't have much success in the beginning of the weekend, I'll go back to an earlier OS.

I don't know if I can file a bug with Apple without paying their $100 registration fee, and I hear their forums are pretty slow so don't know if it's worth it.  I imagine a fix will appear in future updates....

Journeyman III

*UPDATE*; here is a partial copy of what I've posted on the AMD board:


It turns out the error I quoted was generated by almost the first executable line in my kernel, where I was clearly adding an int32 to a float4; presumably it was auto-converted before because the numbers used to be right.  Adding a (float4) cast to the int32 fixed that.

BUT, now I'm embroiled in more mysterious bugs without any cool diagnostic info; it just tells me what pass it fails on, and my only method to search it down is what I call the "méthode tédieuse", commenting out huge chunks of my kernel to see when it compiles, then cutting the chunks down, then trying again.  I've identified a problem with a tweening function I've had trouble with before, and now need to find another solution for.  Also, some kind of problem with stepping through a character buffer.

It now fails on the 'AMD IL Swizzle Encoder Pass', which is at least two passes later than it used to fail, but that's all it'll give me....

If I find more of a solution, I'll post it here....

Journeyman III

*oops* I meant to say the Khronos board; that and this one seem to be the best....

It seems that what I cannot do is to use the result of the subtraction of two character pointers.  If a and b are both __global char *, I cannot use (b-a) in a calculation, nor can I return (b-a) from a function.  (I can say "int c = b - a" if I don't use the result, presumably because it's optimized away.)  Doesn't help to use ptrdiff_t instead, casts, intermediate variables, nothing.  This particular routine has worked for decades; it's my strpos function....

If I figure this out any further, I'll post again....



If you can get a simplified test case that reproduces the error, I can see if we can reproduce it on the PC side and fix it. The swizzle encoder pass is common across platforms, so the same error should show up.