|Summary:||OpenCL: clBuildProgram prints error messages directly rather than storing them|
|Status:||RESOLVED WORKSFORME||QA Contact:||mesa-dev|
|i915 platform:||i915 features:|
|Bug Depends on:|
Description Luke-Jr 2014-05-12 06:34:52 UTC
Errors should be made accessible via clGetProgramBuildInfo with CL_PROGRAM_BUILD_LOG, not printed directly.
Comment 1 Tom Stellard 2014-05-12 13:31:18 UTC
I though this was working. Can you provide and example of the output when a shader fails to compile.
Comment 2 Luke-Jr 2014-05-12 18:17:22 UTC
(In reply to comment #1) > I though this was working. Can you provide and example of the output when a > shader fails to compile. With my current setup, what happens seems to be LLVM tries to format FROM unallocated memory (which prevents me from using gdb, but "gets away with it" at normal runtime), prints something along the lines of "1 error(s)", CL_PROGRAM_BUILD_LOG yields a null string, and the end result after testing cause my system to lock up. :( Prior to my first lock up, a message about <stddef.h> not being found was also printed (strace showed it checking /usr/include and /usr/include/clc, but not the documented /usr/lib/clang/3.4.1/include which actually has a stddef.h). A few weeks ago, it worked on my 5850, but not 7xxx, which printed (directly) compile errors. I *think* the main change since then was a LLVM upgrade. Although I had to mess around quite a bit to get Open*G*L working again (which turned out to be its SSSE3 memcpy replacement crashing on Haswell).
Comment 3 Tom Stellard 2014-05-12 20:00:00 UTC
Did you upgrade llvm and clang at the same time? Did you do a clean rebuild of Mesa after upgrading? Mesa statically links with clang, so you need to make sure the clover is completely rebuilt after you upgrade llvm/clang.
Comment 4 Vedran Miletić 2017-03-22 16:36:37 UTC
Luke-Jr, please reopen if this is still an issue.