Conversation
|
The Linux failures appear to be a latent, pre-existing bug that compiler changes have revealed. Stay tuned... |
8ab7809 to
33b96df
Compare
…0 committer Steven Johnson <srj@google.com> 1600973808 -0700 Require C++17 for Halide. (We previously required C++11, although Make builds typically ended up using C++14 due to `llvm-config --cxxflags` specifying it.)
33b96df to
b6ddbc1
Compare
|
No rush to land this (we probably want to wait until after the |
apps/bgu/CMakeLists.txt
Outdated
| set(CMAKE_CXX_STANDARD_REQUIRED YES) | ||
| set(CMAKE_CXX_EXTENSIONS NO) | ||
|
|
||
| # MSVC won't set __cplusplus correctly unless this flag is also set |
There was a problem hiding this comment.
Is there no way to hide this idiocy from our users?
There was a problem hiding this comment.
We reported this to the CMake folks and they insisted they couldn't change it without a 'policy' flag to enable it, because existing (broken) code might rely on this (insanely broken) behavior, so they aren't gonna change it anytime soon.
The alternative that most people seem to end up using is to combine sniffing of __cplusplus with sniffing of _MSC_LANG, which would work I guess, but is just so f***ing wrong that I didn't want to do it, just on principle. Maybe that's a more pragmatic approach than requiring the build files to insert extra things to work around bad decisions by both MSVC and CMake.
There was a problem hiding this comment.
Can we move the setting onto our side of the fence somehow, instead of in the user CMakeLists?
There was a problem hiding this comment.
Well, yes and no.
We currently don't need to check __cplusplus at all (there's a reality check in Codegen_LLVM.cpp but it is just as a backstop).
If we only used C++17 features internal to libHalide, then we wouldn't need this.
If we eventually use a C++17 feature in headers exposed to user code (e.g. in templates), though, then we'd definitely have this problem (ie the user code's build system would have to set this flag).
I guess the better answer is to bite the bullet and accept that checks of that sort will have to check both __cplusplus and _MSC_LANG for the foreseeable future, which is just a sorry state of affairs.
There was a problem hiding this comment.
(fix pushed)
For some reason, these are only getting flagged under C++17 builds, but they are legit (minor) issues we want to fix.
v2.4.3 can generate a lot of compiler warnings under C++17; v2.5 fixes there. Note 1: I am unsure about the issues with keeping in sync with Ubuntu 20.04; tagging @alexreinking for comments Note 2: the current version of PyBind11 is actually v2.6, but it has many more changes and upgrading looks nontrivial; deliberately holding off on that upgrade for now.
|
So now that Halide 12 is done, are we ready to land this? Are there any major downstream stakeholders that have any objections? |
README.md
Outdated
| (Note that *using* Halide requires C++11 or later, but *building* Halide | ||
| requires C++17.) | ||
|
|
There was a problem hiding this comment.
This needs to be fixed now that we decided to go C++17 wholesale.
src/Generator.h
Outdated
| inline void build_inputs(std::vector<std::vector<StubInput>> &inputs, int idx) { | ||
| internal_assert(idx == (int)inputs.size()); | ||
| } | ||
|
|
||
| template<typename Last> | ||
| inline void build_inputs(std::vector<std::vector<StubInput>> &inputs, int idx, const Last &last) { | ||
| inputs[idx] = build_input(idx, last); | ||
| } | ||
|
|
||
| template<typename First, typename Second, typename... Rest> | ||
| inline void build_inputs(std::vector<std::vector<StubInput>> &inputs, int idx, const First &first, const Second &second, const Rest &...rest) { | ||
| build_inputs<First>(inputs, idx, first); | ||
| build_inputs<Second, Rest...>(inputs, idx + 1, second, rest...); |
There was a problem hiding this comment.
Since we're going full C++17, this can be reverted, right?
|
All green (again). Are we ready to land this? |
| @@ -136,6 +136,7 @@ int main(int argc, char **argv) { | |||
|
|
|||
There was a problem hiding this comment.
...huh, weird, will revert
|
No objections here. |
README_cmake.md
Outdated
| The next three variables set the project-wide C++ standard. The first, | ||
| [`CMAKE_CXX_STANDARD`][cmake_cxx_standard], simply sets the standard version. | ||
| Halide requires at least C++11. The second, | ||
| Halide requires at least c++17. The second, |
There was a problem hiding this comment.
@steven-johnson - can you fix this one little thing before merging? No need to wait on buildbots for this, obviously.
|
We have discussed this quite a lot at dev meetings, so I think it's good to just land at this point without waiting for explicit approvals from everyone. It can always be rolled back if someone has a serious complaint. |
As of Halide 13, we require C++17 to build or use Halide. (We previously claimed to require C++11, although Make builds typically ended up using C++14 due to
llvm-config --cxxflagsspecifying it.)Fixes #4216