7 ms·

LLVM 10.0

197 points by zmodem 7y ago

marmaduke 7y ago
I feel like LLVM 3.4 and GCC 4.8 were around for ages and now they increment major versions every time I reinstall Linux. Is it just me? Why do compiler version numbers increase so faster now? (I read these release notes, it seems quite nice but is it a major version?)
- ktta 7y ago
  They changed the way versioning is done around 3.9's release. http://blog.llvm.org/2016/12/llvms-new-versioning-scheme.html http://blog.llvm.org/2016/12/llvms-new-versioning-scheme.htm... I feel they are changing the version too quickly (I usually keep an eye out for the major version bumps, and with LLVM I just ignore them now)
  - eslaught 7y ago
    Here's the HN discussion from when this was posted: https://news.ycombinator.com/item?id=13179903 https://news.ycombinator.com/item?id=13179903 Personally, though I agree the version number is going up too quickly, I appreciate that it at least aligns with their policy on breaking changes (which is to provide no hard guarantees on backwards compatibility).
  - loeg 7y ago
    Ditto GCC after 4.x.[1] 4.0.0-4.9.4 (last) was Apr 2005 - Dec 2016. Almost 12 years. Starting in 5.x they dropped the 3rd release digit and started bumping the major version more frequently. Between Apr 2015 and the present, GCC has put out 5.x, 6.x, 7.x, 8.x, and 9.x. [1]: https://gcc.gnu.org/releases.html https://gcc.gnu.org/releases.html
  - aseipp 7y ago
    Why would you ignore it because of that? LLVM's release cycle is short-ish, but its version bumps are precisely the kind you should pay attention to -- it's a project that changes rapidly with a large amount of features and many stakeholders. Breaks, as well as major new functionality, are common between releases. I don't see why the version today being 12 or 4.10 or whatever makes a difference to this. It's extremely worth keeping an eye on if you're invested in LLVM either way (as a user, downstream consumer, corporation, whatever.) This has been true since major corporate involvement started as long as 10 years ago or more... If anything, as another user mentioned, this version scheme is probably more honest to the way LLVM actually works anyway, because in practice every release has major breaking changes, and this scheme (in theory) better reflects that. At least with Firefox, most versions N and N+1 don't just visibly break tons of functionality for a user, so you could argue the increase is too rapid for what are (mostly) incremental changes. But LLVM's client base is much more vulnerable to major change and in practice it does break tons of APIs and make tons of changes release-to-release.
- jpfr 7y ago
  The same is happening with Firefox. Many "infrastructure" software projects have switched to time-based releases. Say, a release every 6 months. So there is no notion of big or small releases. Hence the seemingly fast increase of version numbers.
  - sdegutis 7y ago
    It makes sense. Version numbers should be intuitive. Constantly changing software should update by whole numbers, so that the more it has changed, the more the number is different. Whereas "3.11" seems almost identical to "3.86" because they're both based on 3. Although I would argue that it should change by 0.5 per feature or something like that, so that if it has 10 new features the version number will be 5 higher, but only 2 new features will be 1 higher. Because Java has changed very little from 8 to 12, whereas Firefox's last 4 changes were altogether bigger.
  - asveikau 7y ago
    You can still do a time based release without jumping major versions so often. Eg. OpenBSD's version number increments by 0.1 every six months and has done that for more than 20 years.
- tveita 7y ago
  Numba the Python library is only just getting around to support LLVM 9. https://github.com/numba/llvmlite/issues/523 https://github.com/numba/llvmlite/issues/523
- klodolph 7y ago
  2.x - 9 years 3.x - 4 years 4.x - 10 years Honestly, if nothing else, I hated seeing all the #if defined __GNUC__ && (__GNUC__ > 4 || __GNUC__ == 4 && __GNUC_MINOR__ >= 2)
  - wahern 7y ago
    Fortunately these days you're supposed to use __has_attribute, __has_extension, and __has_builtin. But I'm not sure if, overall, things have gotten better. For example, overly eager diagnostic warnings have come at the cost of an increased need to disable diagnostics--perfectly standard-compliant code, not to mention widely supported extensions, will often trigger diagnostics with -Wall. You can disable those inline (and I try, because good luck trying to figure out what's the equivalent of CFLAGS in the build pipeline du jour, or simply expecting the user to figure it out), but they often have different names in different compilers and sometimes you have to resort to version guards to maintain a diagnostic-free build out-of-the-box. Also, the default compiler on RHEL7 is GCC 4.8, which lacks __has_attribute and friends, among other things. EOL for RHEL7 is 2024! And __has_builtin didn't even come around until GCC 10, and didn't work reliably prior to clang 11.
  - loeg 7y ago
    4.x ran for nearly 12 years actually! April 2005 to 4.9.4 in December 2016. The 4.3.0 release was significant for at least two reasons: 1. True C99 "inline" support 2. Switch to the GPL3
    - klodolph 7y ago
      Counting time from 4-5, not time to last release in the 4 series.
      - loeg 7y ago
        Sure! It's a long time either way.
- hadlock 7y ago
  Postgres moved to this model somewhat recently. Two years ago we were talking about doing "the postgres 10 conversion" and now they're up to pg v. 12, or maybe higher already, I haven't checked. Semi-annual releases are nice, features ship when they are ready, and releases aren't delayed because that feature that's taking just a tiny bit longer than expected, well, it'll be fully baked by next year's release.
deleted 7y ago
[deleted]
genpfault 7y ago
Can you build clang with clang yet on Windows without Visual Studio installed?
- tiagoma 7y ago
  you always could, no? Just tell cmake to use clang to compile
  - deleted 7y ago
    [deleted]
  - BubRoss 7y ago
    libc++ was a big problem for a long time, I'm not sure if that ever got ironed out properly or became easier.
- muststopmyths 7y ago
  I use makefiles and that works fine. Haven't gotten CMake to work because it specifically expects clang-cl, not clang.
AndyKelley 7y ago
If you want to play around with some of the improved code generation features of Clang/LLVM 10 for various architectures (MIPS, ARM, RISC-V, etc), but don't want to take the time to set up a full cross compilation environment, you could use the master branch tarballs[1] of Zig, which already are based on LLVM/Clang 10. I just published a blog post[2] about this. You can use `zig cc` in the place of `clang`, and it'll unlock cross compilation. [1]: https://ziglang.org/download/ https://ziglang.org/download/ [2]: https://andrewkelley.me/post/zig-cc-powerful-drop-in-replacement-gcc-clang.html https://andrewkelley.me/post/zig-cc-powerful-drop-in-replace...
- blindseer 7y ago
  Thank you Andrew for all the work you've done on this! I'm very excited about being able to download zig and get the latest LLVM version AND be able to cross compile in a single go. `zig cc` in some ways is now a better C compiler than clang/gcc. To me that's even crazier than everything else that is happening in the world right now.
- mamcx 7y ago
  This is great. Is possible to compile to memory alike tinycc (ie: to make a interpreter/JIT without going assembly)?
- rurban 7y ago
  Does not really look like a drop-in replacement for cc yet. The zip-install-prefix path is not relative and unknown. It is not taken from the downloaded path. The linker and autotools integration does not work yet. But it almost works. e.g. --disable-shared CC="zig cc --target=x86_64-linux-musl" LD=lld
floatboth 7y ago
> Clang now defaults to .init_array on Linux. It used to use .ctors if the found GCC installation is older than 4.7.0 Oh man, I've seen that check somewhere.. namely, I've had to port the init-array-or-ctors decision code from clang to LDC, because LDC was just using LLVM defaults, and LLVM defaulted to ctors on FreeBSD/AArch64, which doesn't support ctors, but that was only noticeable with the LLD linker, because bfd and gold were quietly (!) converting ctors to init_array (!!) as a performance optimization (!!!) ref: https://github.com/ldc-developers/druntime/pull/146#issuecomment-433229535 https://github.com/ldc-developers/druntime/pull/146#issuecom...
chaz6 7y ago
Is it feasible to deliver a compiler as a standalone executable (e.g. * .appimage on linux or * .exe on windows)? Edit: couldn't find how to use a raw * next to text without it changing the formatting in HN.

197 points by zmodem 7y ago

I feel like LLVM 3.4 and GCC 4.8 were around for ages and now they increment major versions every time I reinstall Linux. Is it just me? Why do compiler version numbers increase so faster now? (I read these release notes, it seems quite nice but is it a major version?)

ktta 7y ago
They changed the way versioning is done around 3.9's release. http://blog.llvm.org/2016/12/llvms-new-versioning-scheme.html http://blog.llvm.org/2016/12/llvms-new-versioning-scheme.htm... I feel they are changing the version too quickly (I usually keep an eye out for the major version bumps, and with LLVM I just ignore them now)
- eslaught 7y ago
  Here's the HN discussion from when this was posted: https://news.ycombinator.com/item?id=13179903 https://news.ycombinator.com/item?id=13179903 Personally, though I agree the version number is going up too quickly, I appreciate that it at least aligns with their policy on breaking changes (which is to provide no hard guarantees on backwards compatibility).
- loeg 7y ago
  Ditto GCC after 4.x.[1] 4.0.0-4.9.4 (last) was Apr 2005 - Dec 2016. Almost 12 years. Starting in 5.x they dropped the 3rd release digit and started bumping the major version more frequently. Between Apr 2015 and the present, GCC has put out 5.x, 6.x, 7.x, 8.x, and 9.x. [1]: https://gcc.gnu.org/releases.html https://gcc.gnu.org/releases.html
- aseipp 7y ago
  Why would you ignore it because of that? LLVM's release cycle is short-ish, but its version bumps are precisely the kind you should pay attention to -- it's a project that changes rapidly with a large amount of features and many stakeholders. Breaks, as well as major new functionality, are common between releases. I don't see why the version today being 12 or 4.10 or whatever makes a difference to this. It's extremely worth keeping an eye on if you're invested in LLVM either way (as a user, downstream consumer, corporation, whatever.) This has been true since major corporate involvement started as long as 10 years ago or more... If anything, as another user mentioned, this version scheme is probably more honest to the way LLVM actually works anyway, because in practice every release has major breaking changes, and this scheme (in theory) better reflects that. At least with Firefox, most versions N and N+1 don't just visibly break tons of functionality for a user, so you could argue the increase is too rapid for what are (mostly) incremental changes. But LLVM's client base is much more vulnerable to major change and in practice it does break tons of APIs and make tons of changes release-to-release.
jpfr 7y ago
The same is happening with Firefox. Many "infrastructure" software projects have switched to time-based releases. Say, a release every 6 months. So there is no notion of big or small releases. Hence the seemingly fast increase of version numbers.
- sdegutis 7y ago
  It makes sense. Version numbers should be intuitive. Constantly changing software should update by whole numbers, so that the more it has changed, the more the number is different. Whereas "3.11" seems almost identical to "3.86" because they're both based on 3. Although I would argue that it should change by 0.5 per feature or something like that, so that if it has 10 new features the version number will be 5 higher, but only 2 new features will be 1 higher. Because Java has changed very little from 8 to 12, whereas Firefox's last 4 changes were altogether bigger.
- asveikau 7y ago
  You can still do a time based release without jumping major versions so often. Eg. OpenBSD's version number increments by 0.1 every six months and has done that for more than 20 years.
tveita 7y ago
Numba the Python library is only just getting around to support LLVM 9. https://github.com/numba/llvmlite/issues/523 https://github.com/numba/llvmlite/issues/523
klodolph 7y ago
2.x - 9 years 3.x - 4 years 4.x - 10 years Honestly, if nothing else, I hated seeing all the #if defined __GNUC__ && (__GNUC__ > 4 || __GNUC__ == 4 && __GNUC_MINOR__ >= 2)
- wahern 7y ago
  Fortunately these days you're supposed to use __has_attribute, __has_extension, and __has_builtin. But I'm not sure if, overall, things have gotten better. For example, overly eager diagnostic warnings have come at the cost of an increased need to disable diagnostics--perfectly standard-compliant code, not to mention widely supported extensions, will often trigger diagnostics with -Wall. You can disable those inline (and I try, because good luck trying to figure out what's the equivalent of CFLAGS in the build pipeline du jour, or simply expecting the user to figure it out), but they often have different names in different compilers and sometimes you have to resort to version guards to maintain a diagnostic-free build out-of-the-box. Also, the default compiler on RHEL7 is GCC 4.8, which lacks __has_attribute and friends, among other things. EOL for RHEL7 is 2024! And __has_builtin didn't even come around until GCC 10, and didn't work reliably prior to clang 11.
- loeg 7y ago
  4.x ran for nearly 12 years actually! April 2005 to 4.9.4 in December 2016. The 4.3.0 release was significant for at least two reasons: 1. True C99 "inline" support 2. Switch to the GPL3
  - klodolph 7y ago
    Counting time from 4-5, not time to last release in the 4 series.
    - loeg 7y ago
      Sure! It's a long time either way.
hadlock 7y ago
Postgres moved to this model somewhat recently. Two years ago we were talking about doing "the postgres 10 conversion" and now they're up to pg v. 12, or maybe higher already, I haven't checked. Semi-annual releases are nice, features ship when they are ready, and releases aren't delayed because that feature that's taking just a tiny bit longer than expected, well, it'll be fully baked by next year's release.

deleted 7y ago

[deleted]

genpfault 7y ago

Can you build clang with clang yet on Windows without Visual Studio installed?

tiagoma 7y ago
you always could, no? Just tell cmake to use clang to compile
- deleted 7y ago
  [deleted]
- BubRoss 7y ago
  libc++ was a big problem for a long time, I'm not sure if that ever got ironed out properly or became easier.
muststopmyths 7y ago
I use makefiles and that works fine. Haven't gotten CMake to work because it specifically expects clang-cl, not clang.

AndyKelley 7y ago

If you want to play around with some of the improved code generation features of Clang/LLVM 10 for various architectures (MIPS, ARM, RISC-V, etc), but don't want to take the time to set up a full cross compilation environment, you could use the master branch tarballs[1] of Zig, which already are based on LLVM/Clang 10. I just published a blog post[2] about this. You can use `zig cc` in the place of `clang`, and it'll unlock cross compilation. [1]: https://ziglang.org/download/ https://ziglang.org/download/ [2]: https://andrewkelley.me/post/zig-cc-powerful-drop-in-replacement-gcc-clang.html https://andrewkelley.me/post/zig-cc-powerful-drop-in-replace...

blindseer 7y ago
Thank you Andrew for all the work you've done on this! I'm very excited about being able to download zig and get the latest LLVM version AND be able to cross compile in a single go. `zig cc` in some ways is now a better C compiler than clang/gcc. To me that's even crazier than everything else that is happening in the world right now.
mamcx 7y ago
This is great. Is possible to compile to memory alike tinycc (ie: to make a interpreter/JIT without going assembly)?
rurban 7y ago
Does not really look like a drop-in replacement for cc yet. The zip-install-prefix path is not relative and unknown. It is not taken from the downloaded path. The linker and autotools integration does not work yet. But it almost works. e.g. --disable-shared CC="zig cc --target=x86_64-linux-musl" LD=lld

floatboth 7y ago

> Clang now defaults to .init_array on Linux. It used to use .ctors if the found GCC installation is older than 4.7.0 Oh man, I've seen that check somewhere.. namely, I've had to port the init-array-or-ctors decision code from clang to LDC, because LDC was just using LLVM defaults, and LLVM defaulted to ctors on FreeBSD/AArch64, which doesn't support ctors, but that was only noticeable with the LLD linker, because bfd and gold were quietly (!) converting ctors to init_array (!!) as a performance optimization (!!!) ref: https://github.com/ldc-developers/druntime/pull/146#issuecomment-433229535 https://github.com/ldc-developers/druntime/pull/146#issuecom...

chaz6 7y ago

Is it feasible to deliver a compiler as a standalone executable (e.g. * .appimage on linux or * .exe on windows)? Edit: couldn't find how to use a raw * next to text without it changing the formatting in HN.