-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Simple xocc test fails to compile in hw_emu mode #22
Comments
@j-stephan, could you try to remove |
@bader, yes, compilation in Edit 23 May '19: Removing |
@j-stephan, thanks for confirming. We will send a patch to https://github.com/intel/llvm removing these problematic stubs shortly. |
Great news, thanks! And a follow-up for the Xilinx folks: When setting
The full compiler log (when calling |
This is one of those unfortunate occasions where I can't seem to recreate the problem on my machine (2018.3 branch XRT, SDx 2018.3 with the build time stamp, same FPGA platform and the same unmodified branch of the compiler), so it doesn't appear to be an issue with the SYCL compiler itself. So the error in the log is: ERROR: [XSIM 43-3409] Failed to compile generated C file xsim.dir/emu_wrapper_behav/obj/xsim_4.c. Which is unfortunately a little unspecific (like a lot of the Xilinx tool chain errors unfortunately). From looking around the most likely cause is missing library files in your system for xsim to link against. So this thread fixed it by installing the build-essential package: https://forums.xilinx.com/t5/Simulation-and-Verification/Vivado-2017-2-Simulation-XSIM-43-3409-Failed-to-compile/td-p/856475 And the following thread shows how to track errors like this down: https://forums.xilinx.com/t5/Simulation-and-Verification/One-solution-to-error-quot-Failed-to-compile-generated-C-file/td-p/865415 The above thread also shows the usage of the settings64.sh file that comes with SDAccel, the current environment setup in the documents is the minimum I needed to run it on my machine with my installed libraries. SDAccel comes packaged with its own libraries though so it's possible the settings64.sh will fix it by linking to the packaged libraries. The downside of using settings64.sh is that it will bloat your environment with a lot of unnecessary variables. Again sorry about having to play technical support in this case as I can't seem to recreate it on my end for the moment. I am of course happy to help, as if it is a missing environment setup step it should be documented. @bader Thanks for replying to the issue and helping out. Also thanks for the fix update, we'll merge it asap when we see it merged in! |
Aside from that, once it compiles the newer version of XRT from the master branch of XRT (2.2.0) doesn't play nice with the xcl binary generated from hardware simulation at the moment. Which I'll need to look into and fix in the near future, so I would stick to the 2018.3 branch for now like you are correctly doing! The XRT from the 2018.3 branch seems to work for the xilinx_u250_xdma_201830_1 but not for the xilinx_u200_xdma_201830_1 at the moment. Some argument buffers are getting inferred to different default DDR banks for each platform (u200 assigns to ddr[1] and the u250 assigns to ddr[0]), which may be some variation of this old error in 2018.2 from the u250 which had a workaround: https://www.xilinx.com/support/answers/71596.html The version I was previously testing with and that was working reasonably well (in the sense that it was running the executable, I imagine the newer XRT is more accurately simulating hardware and that's the source of the errors) was XRT 2.1.0 from a while ago (Nov 12 15:59:21 2018)!, the commit hash is: e45216d98a2940d5b46534a8f8c8c33dfae6787c So perhaps you'll have more success with the U200 there for the time being... I think the main take away from this for me is that I need to do some more hardware simulation tests and fixes to account for the newer changes to XRT at the moment.. |
Wow, thanks for the very detailed response(s)!
This was the solution! Turns out I had the same issue with Xilinx' bundled
Edit:
So the correct way to do this would be like in the following link, right? Create a custom OpenCL buffer and pass it on to SYCL? https://forums.xilinx.com/t5/SDAccel/use-multi-DDR-bank-in-SDAccel-is-not-wrok/td-p/809363 Or is there a nice SYCL way I'm missing? Edit 2: Compilation also worked in |
No problem, happy that it helped! I think I'll leave it open for the moment in case anyone else runs into a similar problem and to remind me to add it to the documentation under perhaps a "Diagnosing Environment Problems" or "Common Problems" section as it seems to be useful information. Our tools can be a little difficult to integrate first time around, the Xilinx trial by fire. As for the buffer inference problem, I've not had time to look into it just yet (if you find a fix I'd be ecstatic to hear about it), but that's probably one avenue of fixing/working around it, using the OpenCL interoperability components of SYCL. I haven't done a lot of testing with the OpenCL interoperability components of the runtime yet, so I'm unsure how well it will work. A more long-term and SYCL'y fix (and I still need to find some time to tinker with this to see if it is actually the problem) would be to adjust the sycl/source/scheduler/commands.cpp when it's setting the kernel arguments via clSetKernelArg. That way the user would hopefully never be forced to use the interop components and the compiler would ideally never have to make assumptions. It may not be as easy as that though, I still need to invest some time into this particular problem and I think my future plans will be to work on cleaning up the driver (I'll talk to @keryell when he gets back from the Khronos F2F next week). |
The problem previously mentioned about inferred DDR Banks should be fixed by this pull request: #27 It's an imperfect fix though, it forces everything into DDR bank 0 for now. Ideally we'd eventually end up with a way for users to easily specify DDR bank and SLR assignment, a future consideration for now though. |
CONFLICT (content): Merge conflict in clang/lib/Driver/ToolChains/Clang.cpp
This seems to be fixed, I can compile in |
Found by msan -fsanitize-memory-use-after-dtor. ==8259==WARNING: MemorySanitizer: use-of-uninitialized-value #0 0x55dbec54d2b8 in dtorRecord(clang::interp::Block*, char*, clang::interp::Descriptor*) clang/lib/AST/Interp/Descriptor.cpp:150:22 #1 0x55dbec54bfcf in dtorArrayDesc(clang::interp::Block*, char*, clang::interp::Descriptor*) clang/lib/AST/Interp/Descriptor.cpp:97:7 #2 0x55dbec508578 in invokeDtor clang/lib/AST/Interp/InterpBlock.h:79:7 #3 0x55dbec508578 in clang::interp::Program::~Program() clang/lib/AST/Interp/Program.h:55:19 #4 0x55dbec50657a in operator() third_party/crosstool/v18/stable/toolchain/bin/../include/c++/v1/__memory/unique_ptr.h:55:5 #5 0x55dbec50657a in std::__msan::unique_ptr<clang::interp::Program, std::__msan::default_delete<clang::interp::Program>>::~unique_ptr() third_party/crosstool/v18/stable/toolchain/bin/../include/c++/v1/__memory/unique_ptr.h:261:7 #6 0x55dbec5035a1 in clang::interp::Context::~Context() clang/lib/AST/Interp/Context.cpp:27:22 #7 0x55dbebec1daa in operator() third_party/crosstool/v18/stable/toolchain/bin/../include/c++/v1/__memory/unique_ptr.h:55:5 #8 0x55dbebec1daa in std::__msan::unique_ptr<clang::interp::Context, std::__msan::default_delete<clang::interp::Context>>::~unique_ptr() third_party/crosstool/v18/stable/toolchain/bin/../include/c++/v1/__memory/unique_ptr.h:261:7 #9 0x55dbebe285f9 in clang::ASTContext::~ASTContext() clang/lib/AST/ASTContext.cpp:1038:40 #10 0x55dbe941ff13 in llvm::RefCountedBase<clang::ASTContext>::Release() const llvm/include/llvm/ADT/IntrusiveRefCntPtr.h:101:7 #11 0x55dbe94353ef in release llvm/include/llvm/ADT/IntrusiveRefCntPtr.h:159:38 #12 0x55dbe94353ef in release llvm/include/llvm/ADT/IntrusiveRefCntPtr.h:224:7 #13 0x55dbe94353ef in ~IntrusiveRefCntPtr llvm/include/llvm/ADT/IntrusiveRefCntPtr.h:191:27 #14 0x55dbe94353ef in clang::CompilerInstance::setASTContext(clang::ASTContext*) clang/lib/Frontend/CompilerInstance.cpp:178:3 #15 0x55dbe95ad0ad in clang::FrontendAction::EndSourceFile() clang/lib/Frontend/FrontendAction.cpp:1100:8 #16 0x55dbe9445fcf in clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) clang/lib/Frontend/CompilerInstance.cpp:1047:11 #17 0x55dbe6b3afef in clang::ExecuteCompilerInvocation(clang::CompilerInstance*) clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp:266:25 #18 0x55dbe6b13288 in cc1_main(llvm::ArrayRef<char const*>, char const*, void*) clang/tools/driver/cc1_main.cpp:250:15 #19 0x55dbe6b0095f in ExecuteCC1Tool(llvm::SmallVectorImpl<char const*>&) clang/tools/driver/driver.cpp:319:12 #20 0x55dbe6aff41c in clang_main(int, char**) clang/tools/driver/driver.cpp:395:12 #21 0x7f9be07fa632 in __libc_start_main #22 0x55dbe6a702e9 in _start Member fields were destroyed #0 0x55dbe6a7da5d in __sanitizer_dtor_callback_fields compiler-rt/lib/msan/msan_interceptors.cpp:949:5 #1 0x55dbec5094ac in ~SmallVectorImpl llvm/include/llvm/ADT/SmallVector.h:479:7 #2 0x55dbec5094ac in ~SmallVectorImpl llvm/include/llvm/ADT/SmallVector.h:612:3 #3 0x55dbec5094ac in llvm::SmallVector<clang::interp::Record::Base, 8u>::~SmallVector() llvm/include/llvm/ADT/SmallVector.h:1207:3 #4 0x55dbec508e79 in clang::interp::Record::~Record() clang/lib/AST/Interp/Record.h:24:7 #5 0x55dbec508612 in clang::interp::Program::~Program() clang/lib/AST/Interp/Program.h:49:26 #6 0x55dbec50657a in operator() third_party/crosstool/v18/stable/toolchain/bin/../include/c++/v1/__memory/unique_ptr.h:55:5 #7 0x55dbec50657a in std::__msan::unique_ptr<clang::interp::Program, std::__msan::default_delete<clang::interp::Program>>::~unique_ptr() third_party/crosstool/v18/stable/toolchain/bin/../include/c++/v1/__memory/unique_ptr.h:261:7 #8 0x55dbec5035a1 in clang::interp::Context::~Context() clang/lib/AST/Interp/Context.cpp:27:22 #9 0x55dbebec1daa in operator() third_party/crosstool/v18/stable/toolchain/bin/../include/c++/v1/__memory/unique_ptr.h:55:5 #10 0x55dbebec1daa in std::__msan::unique_ptr<clang::interp::Context, std::__msan::default_delete<clang::interp::Context>>::~unique_ptr() third_party/crosstool/v18/stable/toolchain/bin/../include/c++/v1/__memory/unique_ptr.h:261:7 #11 0x55dbebe285f9 in clang::ASTContext::~ASTContext() clang/lib/AST/ASTContext.cpp:1038:40 #12 0x55dbe941ff13 in llvm::RefCountedBase<clang::ASTContext>::Release() const llvm/include/llvm/ADT/IntrusiveRefCntPtr.h:101:7 #13 0x55dbe94353ef in release llvm/include/llvm/ADT/IntrusiveRefCntPtr.h:159:38 #14 0x55dbe94353ef in release llvm/include/llvm/ADT/IntrusiveRefCntPtr.h:224:7 #15 0x55dbe94353ef in ~IntrusiveRefCntPtr llvm/include/llvm/ADT/IntrusiveRefCntPtr.h:191:27 #16 0x55dbe94353ef in clang::CompilerInstance::setASTContext(clang::ASTContext*) clang/lib/Frontend/CompilerInstance.cpp:178:3 #17 0x55dbe95ad0ad in clang::FrontendAction::EndSourceFile() clang/lib/Frontend/FrontendAction.cpp:1100:8 #18 0x55dbe9445fcf in clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) clang/lib/Frontend/CompilerInstance.cpp:1047:11 #19 0x55dbe6b3afef in clang::ExecuteCompilerInvocation(clang::CompilerInstance*) clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp:266:25 #20 0x55dbe6b13288 in cc1_main(llvm::ArrayRef<char const*>, char const*, void*) clang/tools/driver/cc1_main.cpp:250:15 #21 0x55dbe6b0095f in ExecuteCC1Tool(llvm::SmallVectorImpl<char const*>&) clang/tools/driver/driver.cpp:319:12 #22 0x55dbe6aff41c in clang_main(int, char**) clang/tools/driver/driver.cpp:395:12 #23 0x7f9be07fa632 in __libc_start_main #24 0x55dbe6a702e9 in _start
I followed the build instructions in
GetStartedWithSYCLCompiler.md
and tried to compile the test case mentioned inXilinxFPGACompilation.md
. This produces the following error message:Similar messages are following for lines
502:47
,507:40
,510:40
,513:52
,516:33
,527:47
,531:47
,536:40
,539:40
,542:52
,545:33
,549:1
,553:1
,556:58
,561:1
,564:42
, and567:42
insycl_wrappers/algorithm
.The system is a fresh Ubuntu 18.10 installation with SDAccel 2018.3 and a self-compiled XRT (2018.3 branch). I'm using the
sycl/unified/master
branch which is up-to-date as of writing this issue.The text was updated successfully, but these errors were encountered: