This is an archive of the discontinued LLVM Phabricator instance.

[CUDA] [test-suite] Always enable assert()s in our builds.
ClosedPublic

Authored by jlebar on Sep 15 2016, 9:16 PM.

Diff Detail

Repository
rL LLVM

Event Timeline

jlebar updated this revision to Diff 71595.Sep 15 2016, 9:16 PM
jlebar retitled this revision from to [CUDA] [test-suite] Always enable assert()s in our builds..
jlebar updated this object.
jlebar added reviewers: tra, jhen.
jlebar added a subscriber: llvm-commits.

I am not sure if there is a better way to do this? I tried a bunch of things and could not manage to get rid of the -DNDEBUG that was (somehow) appearing when we would build the tests.

Friendly ping.

MatzeB added a subscriber: MatzeB.Sep 26 2016, 5:38 PM

NDEBUG is currently enable globally in the toplevel CMakeLists.txt, as it is claimed that some tests fail without it (I don't know which ones and it feels like a hack to me to enable it globally). In any case we could move -DNDEBUG from the global CMakeLists.txt file to {SingleSource|MultiSource|External}/CMakeLists.txt (or even further down the hierarchy when we know which tests actually need it for correctness).

In any case we could move -DNDEBUG from the global CMakeLists.txt file to {SingleSource|MultiSource|External}/CMakeLists.txt (or even further down the hierarchy when we know which tests actually need it for correctness).

It sounds like this would have impacts on all of the other LLVM projects, though? In which case maybe what we have here is the least bad option?

In any case we could move -DNDEBUG from the global CMakeLists.txt file to {SingleSource|MultiSource|External}/CMakeLists.txt (or even further down the hierarchy when we know which tests actually need it for correctness).

It sounds like this would have impacts on all of the other LLVM projects, though? In which case maybe what we have here is the least bad option?

as long as you just push it the setting down the tree and just not into the CUDA directory, it shouldn't affect anyone. Also -DNDEBUG is used by default in the Release build setting which are default as well in the testsuite so the flag is only missing if someone explicitely overrides the flags.

as long as you just push it the setting down the tree and just not into the CUDA directory, it shouldn't affect anyone.

I'm confused: If pushing the -DNDEBUG down in the llvm directory structure would have no effect on other projects (e.g. clang, lldb), why *would* it have an effect on the CUDA code in the test-suite? Or are you saying the test-suite is special in this respect?

Sorry for being so clueless here. /me just wants his asserts.

tra accepted this revision.Sep 27 2016, 11:48 AM
tra edited edge metadata.

I guess we need something like -DLLVM_ENABLE_ASSERTIONS=On we use for LLVM to keeps assert enabled in Release build.
I'm OK with -UNDEBUG for CUDA until I get a chance to add ENABLE_ASSERTIONS knob (~EOW).

This revision is now accepted and ready to land.Sep 27 2016, 11:48 AM
In D24647#554226, @tra wrote:

I guess we need something like -DLLVM_ENABLE_ASSERTIONS=On we use for LLVM to keeps assert enabled in Release build.
I'm OK with -UNDEBUG for CUDA until I get a chance to add ENABLE_ASSERTIONS knob (~EOW).

Yes the -UNDEBUG solution is good enough to put into the repo, I did not want to stop the commit.

Just took the opportunity to note that setting flags for the whole test-suite in the toplevel CMakeLists.txt is generally a bad idea esp. when there is no way to override it. (As far as options go I would not add a TEST_SUITE_ENABLE_ASSERTIONS, simply because for a normal test-suite user there is little motivation to enable assertions, there is always the option to override the cflags/cxxflags after all).

tra added a comment.Sep 27 2016, 12:52 PM

Just took the opportunity to note that setting flags for the whole test-suite in the toplevel CMakeLists.txt is generally a bad idea esp. when there is no way to override it. (As far as options go I would not add a TEST_SUITE_ENABLE_ASSERTIONS, simply because for a normal test-suite user there is little motivation to enable assertions, there is always the option to override the cflags/cxxflags after all).

OK. We'll deal with that if/when we have specific need to enable/disable assertions during config time.

This revision was automatically updated to reflect the committed changes.

OK, thanks folks!