| Summary: | OpenCL: clBuildProgram prints error messages directly rather than storing them | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Luke-Jr <luke-jr+freedesktopbugs> |
| Component: | Other | Assignee: | mesa-dev |
| Status: | RESOLVED WORKSFORME | QA Contact: | mesa-dev |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | 10.0 | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Bug Depends on: | |||
| Bug Blocks: | 99553 | ||
|
Description
Luke-Jr
2014-05-12 06:34:52 UTC
I though this was working. Can you provide and example of the output when a shader fails to compile. (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). 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. Luke-Jr, please reopen if this is still an issue. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.