LLVM 6.0.0 Release
lists.llvm.org
LLVM 6.0.0 Release
1–10 of 33 posts
Re: LLVM 6.0.0 Release
#2Would love to see better transparency from Apple with regards to their adoption/flavour of Clang. The current and next versions of Xcode (9.2 and 9.3) still do not support std::variant/std::optional in Cpp17 for example…
Re: LLVM 6.0.0 Release
#3Would love to see better transparency from Apple with regards to their adoption/flavour of Clang. The current and next versions of Xcode (9.2 and 9.3) still do not support std::variant/std::optional in Cpp17 for example…
I can't remember, has Apple bothered enabling thread-local storage in its clang distribution yet?
Re: LLVM 6.0.0 Release
#4Would love to see better transparency from Apple with regards to their adoption/flavour of Clang. The current and next versions of Xcode (9.2 and 9.3) still do not support std::variant/std::optional in Cpp17 for example…
Apple's LLVM and Clang from Xcode 9 are based on version 4.0 of the main LLVM/Clang. You'll need at least LLVM/Clang 5.0 for more C++17 compatibility.
To be fair, modern C++ support is not a priority for Apple, their efforts are more toward Swift.
Re: LLVM 6.0.0 Release
#5Would love to see better transparency from Apple with regards to their adoption/flavour of Clang. The current and next versions of Xcode (9.2 and 9.3) still do not support std::variant/std::optional in Cpp17 for example…
Chances are the next macOS upgrade will come with an Xcode upgrade which usually comes with an llvm/clang upgrade... but I do agree with you.
Re: LLVM 6.0.0 Release
#6Would love to see better transparency from Apple with regards to their adoption/flavour of Clang. The current and next versions of Xcode (9.2 and 9.3) still do not support std::variant/std::optional in Cpp17 for example…
I can't remember, has Apple bothered enabling thread-local storage in its clang distribution yet?
The last time I checked, only for POC. In my uuid library [0], macOS is basically the only one I can’t create a per-thread rng and instead have to spin up a new one each time.
Re: LLVM 6.0.0 Release
#7Earlier quoted context omitted.
I can't remember, has Apple bothered enabling thread-local storage in its clang distribution yet?
The last time I checked, only for POC. In my uuid library [0], macOS is basically the only one I can’t create a per-thread rng and instead have to spin up a new one each time. 0: https://github.com/neosmart/uuidxx
It's frustrating, because TLS works fine on vanilla clang or newish gcc on Mac OS x.
Re: LLVM 6.0.0 Release
#8Would love to see better transparency from Apple with regards to their adoption/flavour of Clang. The current and next versions of Xcode (9.2 and 9.3) still do not support std::variant/std::optional in Cpp17 for example…
Chances are the next macOS upgrade will come with an Xcode upgrade which usually comes with an llvm/clang upgrade... but I do agree with you.
The problem is that Apple uses its own version numbers for clang, making feature detection difficult. See e.g. http://www.agner.org/optimize/vectorclass/read.php?i=156
Re: LLVM 6.0.0 Release
#9Any benchmarks yet?
Re: LLVM 6.0.0 Release
#10Would love to see better transparency from Apple with regards to their adoption/flavour of Clang. The current and next versions of Xcode (9.2 and 9.3) still do not support std::variant/std::optional in Cpp17 for example…
Apple's LLVM and Clang from Xcode 9 are based on version 4.0 of the main LLVM/Clang. You'll need at least LLVM/Clang 5.0 for more C++17 compatibility. To be fair, modern C++ support is not a priority for Apple, their efforts are more toward Swift.
It's fine if it's not a priority, but why ship a crippled compiler when they could ship the upstream compiler? ABI issues maybe? (I've heard from OS X users that XCode updates have broken the string ABI multiple times anyway...).
I don't really care too much since I'm not an OS X user, but some people insist on trying to compile/run some of the software I work on on OS X...