Hi Tom,
Thanks for your kind response!
> clang -include /path/to/libclc/headers/clc.h -I
/path/to/libclc/headers -Dcl_clang_storage_class_specifiers -target
amdgcn--amdhsa -mcpu=carrizo $INPUT_FILE -o $OUTPUT_FILE
When I tried to build cos.cl testcase
https://github.com/llvm-mirror/libclc/b
Sorry for my wrong post!
Dear Tom,
hsa-runtime was not available? https://github.com/tstellarAMD/hsa-runtime/
在 2017年06月26日 16:20, Leslie Zhai 写道:
Hi Tom,
Thanks for your kind response!
> clang -include /path/to/libclc/headers/clc.h -I
/path/to/libclc/headers -Dcl_clang_storage_class_specif
Hello,
From my understanding (please correct me if i am wrong) , currently the
error codes returned by lldb-server are completely arbitrary.
Now the SBError class in the public API interface of lldb does contain a
string. I think in erroneous cases, lldb seems to set the String
in the lldb Status
My main concern was that *if* strings are added, there's some
clear documentation about the relationship between the string
and the number to explain what's going on. Based on other
emails in this thread it seems like the numbers are so unreliable that
it might not be worth the trouble.
What abou
The gdb remote protocol documents say the error numbers are not well defined.
They are not meant to have any meaning.
The lldb Status (née Error) objects have different namespaces, some of which
(like the Posix errors) have significant numbering, so the numbers in those
cases are preserved, si
https://bugs.llvm.org/show_bug.cgi?id=33603
Bug ID: 33603
Summary: lldb unable to demangle lambdas in destructors
Product: lldb
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
