Details
Diff Detail
Event Timeline
streamexecutor/include/streamexecutor/StreamExecutor.h | ||
---|---|---|
30 | that |
The getOrDie function seems to be generating an additional 'unchecked error' message when dying. For example, this trivial program (which should obviously generate an error):
#include <streamexecutor/streamexecutor.h> namespace se = ::streamexecutor; int main(int argc, char *argv[]) { se::Platform *platform = se::getOrDie(se::PlatformManager::getPlatformByName("foobar")); return 0; }
generates this output:
Error extracting an expected value: no available platform with name foobar. Program aborted due to an unhandled Error: Error value was Success. (Note: Success values must still be checked prior to being destroyed).
Is this expected?
Thanks for the report, jprice. What you described is not expected behavior. You're right that the error should not be "unhandled".
So far, however, I can't reproduce that behavior. I think the example program you gave should fail in the same way as the example/example executable that is checked into StreamExecutor now. They both die because there is no platform registered for the required name, and they are both wrapped in getOrDie.
When you run the example executable, do you see the same behavior, because I only see the first line:
Error extracting an expected value: no available platform with name CUDA.
and no other error message.
If you are seeing the same problem with the example, I think there may be some difference in the versions of the LLVM support libraries we are using. Do you have a revision number for the LLVM you are using?
Thanks again for your help.
Hmm, maybe a false alarm.
It only seems to happen if I build SE in Release/RelWithDebInfo mode and then compile the test program without passing -DNDEBUG, which I guess conflicts with the SE build which would have used -DNDEBUG. I can't reproduce it with the example for that reason, unless I manually compile it without that flag. If SE is built in Debug mode as well, there is no issue.
It's good to know that we have to be careful with the compiler flags. I'll have to think more about the implications here, but maybe we need to include a se-config tool like llvm-config to help users get the right compiler flags. Or we might rethink the idea of using LLVM's libraries at all.
that