LLVM 10.0 | Hacker News Reader

LLVM 10.0

lists.llvm.org

197 pointszmodem25 comments

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/

[2]: https://andrewkelley.me/post/zig-cc-powerful-drop-in-replace...

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.

This is great. Is possible to compile to memory alike tinycc (ie: to make a interpreter/JIT without going assembly)?

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

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?)

They changed the way versioning is done around 3.9's release.

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)

Here's the HN discussion from when this was posted: 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).

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

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.

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.

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.

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.

Numba the Python library is only just getting around to support LLVM 9.

https://github.com/numba/llvmlite/issues/523

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)

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.

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

Counting time from 4-5, not time to last release in the 4 series.

Sure! It's a long time either way.

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.

> 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#issuecom...

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.

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

you always could, no? Just tell cmake to use clang to compile

libc++ was a big problem for a long time, I'm not sure if that ever got ironed out properly or became easier.

I use makefiles and that works fine. Haven't gotten CMake to work because it specifically expects clang-cl, not clang.

Reply on news.ycombinator.com