after modifying a number of variable declarations from
double to single precision in a (working) .cl file, I now have
a systematic segmentation fault at the clBuildProgram call.
It does not seem to be a syntax error, since the code compiles
properly with another vendor's environment.
Any suggestions on how best to approach a problem like this?
maybe a long shot but you try finding if its due to some formatting errors, that cause the compiler to fail, by building the kernel in CodeXL analyze mode?
Thanks for the suggestion. Unfortunately, trying to analyze the kernel file with CodeXL (latest version 1.5-5364, with latest catalyst driver) also results in a segfault. It is rather frustrating! Looks like I'm going to have to remove the kernels one by one from the .cl file, to see when the segfaults disappear ...
That's happened to me before - I had to modify a loop into an two loops and an if statement to make the compiler quit crashing on me.
Thanks for the heads up, Wolf; did you have an "automated" or at least tolerable way of identifying which kernel the problem was in?
Actually, no - I was optimizing, making small changes and checking the speed, so I immediately knew which change did it.
In case anyone from the compiler team is interested, I think I have tracked down the main cause of my segfaults :
implicit type casting from single to double or double to single.
When I remove all of them, the code compiles, with one or two type casts, still no problem, but when I leave a number
of implicit type casts, the segfault at cl compilation occurs.
While I fully understand that implicit type casting is really not something I should be doing from a numerical correctness point of view,
it would be nice if the compiler were able to warn of the locations where they are being performed (currently, it says nothing at all)
rather than segfaulting!
It's hard to comment what may be the actual reason behind this segfault. However, I agree with you that one cannot expect a segfault against some implicit type casting. If that is the case, it would be really helpful for us if you share a testcase that manifests the issue. Your input can help us to improve the performance of compiler/driver in future.
Thanks for the comment.
I will attempt to whittle down my (long: 15000+ lines of kernel) .cl to something reasonably short
which exhibits the same behaviour, and if successful, will send it to you.