Page MenuHomePhabricator

[StreamExecutor] getOrDie and dieIfError utils

Authored by jhen on Aug 31 2016, 3:47 PM.

Diff Detail


Event Timeline

jhen updated this revision to Diff 69916.Aug 31 2016, 3:47 PM
jhen retitled this revision from to [StreamExecutor] getOrDie and dieIfError utils.
jhen updated this object.
jhen added a reviewer: jlebar.
jhen added subscribers: parallel_libs-commits, jprice.
jlebar accepted this revision.Aug 31 2016, 3:56 PM
jlebar edited edge metadata.
jlebar added inline comments.
30 ↗(On Diff #69916)


This revision is now accepted and ready to land.Aug 31 2016, 3:56 PM
jhen updated this revision to Diff 69923.Aug 31 2016, 4:37 PM
jhen edited edge metadata.
  • Fix comment typo spotted by jlebar
This revision was automatically updated to reflect the committed changes.

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 =

  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?

jhen added a comment.Aug 31 2016, 4:59 PM

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.

jhen added a comment.Aug 31 2016, 6:35 PM

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.