Hi guys,
the attached code causes an assertion in clc:
C:\Program Files (x86)\ATI Stream\bin\x86>clc c:\src\Vision\OpenCLTest\bug.cl
c:\src\Vision\OpenCLTest\bug.cl(3): internal error: assertion failed at:
"c:\opencl\compiler\edg\src\amd_ocl_expr.c", line 610
dot( (float8)(1), (float8)(1) );
^
1 catastrophic error detected in the compilation of "c:\src\Vision\OpenCLTest\b
g.cl".
Compilation aborted.
I suppose the compiler could be doing hardcore checking for standards compliance, and asserting instead of giving an error message, as Section 6.11.5 of the OpenCL standard limits arguments up to float4 for some strange reason. Most of the functions under the "geometric function" heading are trivially generalizable to any dimension though, so I'm not sure why the standard would be so picky. It's very counter intuitive and seems to be needlessly tied to current hardware limitations.
This isn't a huge problem for me or anything, but I thought I'd let you know that I had to go dig in the standard document to figure out what was going on with the assertion. The longer vectors would be a lot more useful if they had the same basic functional support as the shorter ones anyway, if someone here could suggest a change whenever the standard is being revised. It's also very natural to assume such functions will work on longer vectors. It seems this problem should apply to length() normalization() distance() etc as well, so I'd guess that a fair number of people will encounter this at some point.
Anyway, great job on the OpenCL implementation! Most of what I've been able to test so far has worked perfectly and it's really been a joy to work with. 
Apart from that assertion, the only problem that had me scratching my head was that, for some reason, clBuild() will always return INVALID_OPERATION when run under the managed debugger in VS2008. This is true, not only of my homebrew C# wrapper, but also other implementations, like the one in OpenTK. The problem doesn't show up when running with native debugging enabled(Which a perfectly acceptable workaround, with essentially no downside), or on release builds though. Sadly, I'm incapable of generating a problem report beyond simply saying that it doesn't work on my machine, due to the lack of feedback from the runtime.
As far as my wish list goes, a 64 bit version of the dll would be awesome in a future beta, even if it had zero 64 bit features beyond being able to run with a larger address space in CPU mode. I obviously have no idea how such a request conflicts with the current state of your software, but I'm sure I'm not the only one who'd be very happy if someone could pull that off without massive delays to the GPU support.
Thanks again for a great release!
__kernel void CrashCompiler( void ) { dot( (float8)(1), (float8)(1) ); }
