3 ms·

> The board also recommends that f18 evaluate (over time) whether it is reasonably possible to eliminate the dependence on C++’17 features. Alright... > Using

> The board also recommends that f18 evaluate (over time) whether it is reasonably possible to eliminate the dependence on C++’17 features. Alright... > Using C++’17 is not a blocker for inclusion into the project, but will be a blocker for certain other infrastructure (e.g. build bots and integration into official releases), but those may or may not be relevant now given the early state of f18. C++'17 is too new for the developers of the premier C++ compiler to use in their CI? What is this hot garbage!

DannyBee 8y ago
LLVM, like a lot of compilers, tries not to require the latest version of itself to bootstrap. See https://llvm.org/docs/GettingStarted.html#host-c-toolchain-both-compiler-and-standard-library https://llvm.org/docs/GettingStarted.html#host-c-toolchain-b... GCC is similar.
- Ericson2314 8y ago
  They should still be able to CI it on the min version that does work. Eventually c++'17 will be old enough, so definitely the thing to do is just wait.
  - Joky 8y ago
    LLVM supports old platforms: some CI bots are targeting stable Debian, or Ubuntu 14.04. LLVM is currently moving to C++14, which is a pain for some users like TensorFlow for instance which supports Ubuntu 14.04: the c++ standard library is too old. There are technical solutions for everything but for a component like LLVM, not pressuring its users into convoluted workflow is important. Of course the LLVM developpers would love to just use the latest version of the standard all the time. For the library part of the standard, it is worked around by having its own: https://github.com/llvm/llvm-project/blob/master/llvm/include/llvm/ADT/STLExtras.h https://github.com/llvm/llvm-project/blob/master/llvm/includ... (and others in the same directory)
    - Ericson2314 8y ago
      The bootstrapping policy and the capabilities of the CI infra should be decoupled. I'm not not arguing the the policy. In three years when LLVM bumps to C++'17 or whatever, then flang starts obeying. But also I personally think is fine for parts of the project not needed to build C++ to use newer C++. Just use the newly built clang to build flang!
      - Joky 8y ago
        This is ignoring that LLVM is first and before all designed as reusable libraries. Bumping requirements is causing other problems than just being able to build with the just built compiler: namely deployment and integration in other products. For example, you may be forced to isolate components in dynamic library that talks with each others through C APIs and each statically link the C++ standard library. It can become fairly complicated when this does not fit your setup and you get forced into this because LLVM decided to bump their standard.
celrod 8y ago
I saw here they have a document explaining which C++17 features they use and why: https://github.com/flang-compiler/f18/blob/master/documentation/C%2B%2B17.md https://github.com/flang-compiler/f18/blob/master/documentat...
- Ericson2314 8y ago
  Yeah I would cry and quit if I was previously using those and then had to stop doing so.

DannyBee 8y ago

LLVM, like a lot of compilers, tries not to require the latest version of itself to bootstrap. See https://llvm.org/docs/GettingStarted.html#host-c-toolchain-both-compiler-and-standard-library https://llvm.org/docs/GettingStarted.html#host-c-toolchain-b... GCC is similar.

Ericson2314 8y ago
They should still be able to CI it on the min version that does work. Eventually c++'17 will be old enough, so definitely the thing to do is just wait.
- Joky 8y ago
  LLVM supports old platforms: some CI bots are targeting stable Debian, or Ubuntu 14.04. LLVM is currently moving to C++14, which is a pain for some users like TensorFlow for instance which supports Ubuntu 14.04: the c++ standard library is too old. There are technical solutions for everything but for a component like LLVM, not pressuring its users into convoluted workflow is important. Of course the LLVM developpers would love to just use the latest version of the standard all the time. For the library part of the standard, it is worked around by having its own: https://github.com/llvm/llvm-project/blob/master/llvm/include/llvm/ADT/STLExtras.h https://github.com/llvm/llvm-project/blob/master/llvm/includ... (and others in the same directory)
  - Ericson2314 8y ago
    The bootstrapping policy and the capabilities of the CI infra should be decoupled. I'm not not arguing the the policy. In three years when LLVM bumps to C++'17 or whatever, then flang starts obeying. But also I personally think is fine for parts of the project not needed to build C++ to use newer C++. Just use the newly built clang to build flang!
    - Joky 8y ago
      This is ignoring that LLVM is first and before all designed as reusable libraries. Bumping requirements is causing other problems than just being able to build with the just built compiler: namely deployment and integration in other products. For example, you may be forced to isolate components in dynamic library that talks with each others through C APIs and each statically link the C++ standard library. It can become fairly complicated when this does not fit your setup and you get forced into this because LLVM decided to bump their standard.

celrod 8y ago

I saw here they have a document explaining which C++17 features they use and why: https://github.com/flang-compiler/f18/blob/master/documentation/C%2B%2B17.md https://github.com/flang-compiler/f18/blob/master/documentat...

Ericson2314 8y ago
Yeah I would cry and quit if I was previously using those and then had to stop doing so.