With r600g I'm seeing the following assertion failure when I try to run any OpenCL programs: hello_world: /home/tstellar/llvm/include/llvm/Support/CommandLine.h:646: void llvm::cl::per<DataType>::addLiteralOption(const char*, const DT&, const char*) [with DT = llvm::ScheeDAGSDNodes* (*)(llvm::SelectionDAGISel*, llvm::CodeGenOpt::Level), DataType = llvm::ScheeDAGSDNodes* (*)(llvm::SelectionDAGISel*, llvm::CodeGenOpt::Level)]: Assertion `findOptioame) == Values.size() && "Option already exists!"' failed. This assertion failure appears to be caused by static objects that are initialized more than once. The first initialization comes from within clover and the second comes from the pipe_*.so driver when clover loads it. The backtrace for this assertion failure starts with: _GLOBAL__sub_I_SelectionDAGISel.cpp If I run: objdump -t libOpenCL.so.1.0.0 I can see that this symbol is included in the libOpenCL.so.1.0.0 library after the automake changes were merged, but it was not included before the merge. This bug likely also affects the EGL state_tracker with r600g or radeonsi. I will do my best to bisect and see which commit caused this bug, but I'm not sure if bisection through the automake changes is possible.
After bisecting, it looks like I introduced this error on clover with this commit: commit 4148a29ed83d1d85bff3d4e40e847128011c3f20 Author: Tom Stellard <thomas.stellard@amd.com> Date: Fri Jan 11 17:28:35 2013 +0000 targets/opencl: Link against libgallium.la instead of libgallium.a I can confirm that the EGL state tracker suffers from a similar problem, and I'm going to bisect to try to determine the cause of it.
Although I did see the "Option already exists!" failure with EGL with one of the last automake branches before the merge, I'm not seeing it (or any other LLVM related failure) now.
Created attachment 73013 [details] Work around for bug This patch works around the bug by linking against libgallium.a rather than libgallium.la. However, this is not a good solution and we should continue to look for a better one.
(In reply to comment #3) > Created attachment 73013 [details] > Work around for bug > > This patch works around the bug by linking against libgallium.a rather than > libgallium.la. However, this is not a good solution and we should continue > to look for a better one. I've hit this bug again. However, this time the assertion fails when a second pipe_*.so is loaded by libOpenCL.so, so these static objects are no longer being initialized by libOpenCL.so, but they are being initialized by each pipe_*.so that is loaded. It seems like the problem might be the visibility of symbols in libOpenCL.so
Fixed by commit cf69a591e1ad16b590c9ae2eba0da6fa6c4fc741
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.