LWN: Comments on "LLVM 8.0.0 released"

LLVM 8.0.0 released

AndreyK2013 — Mon, 29 Apr 2019 18:48:12 +0000

Finding Bugs in LLVM 8 with PVS-Studio :)

LLVM 8.0.0 released

ncultra — Thu, 21 Mar 2019 12:42:13 +0000

It's a C project, using GCC function and variable attributes, X86_64 built-ins, intel intrinsics, and a lot of extended asm. Nested functions is a feature that would help with some of the re-factoring of messy code that the project needs. In summary, none of these dependencies are without equivalents in clang, but the porting effort is not insignificant. I would like to do it myself and can hopefully justify it using the additional code analysis and security features.

LLVM 8.0.0 released

wahern — Thu, 21 Mar 2019 04:41:14 +0000

Personally I prefer GCC. But I'm curious: which GCC feature(s) are you depending on? Unless it's nested functions, I'd guess you're either using GCC plugins or doing something fancy and cutting-edge with C++. It must be something esoteric (or C++, same difference) if clang lacks functional parity.

LLVM 8.0.0 released

nathanchance — Wed, 20 Mar 2019 20:29:23 +0000

We can build arm{32,64} and ppc{32,64le} defconfig without any out of tree patches as of 5.1-rc1 and LLVM 8.0.0.

arm64 allyesconfig needs this series: https://lore.kernel.org/lkml/20190318025411.98014-1-trong...

asm goto is still a WIP in clang so a set of reverts is needed for x86 (otherwise, defconfig and allyesconfig build without any issues).

https://travis-ci.com/ClangBuiltLinux/continuous-integration

LLVM 8.0.0 released

rahulsundaram — Wed, 20 Mar 2019 19:31:21 +0000

Getting closer but not yet

https://github.com/ClangBuiltLinux/linux/issues

LLVM 8.0.0 released

mchehab — Wed, 20 Mar 2019 16:36:00 +0000

Anyone knows if it already builds the Kernel out of the box? Last time I checked, some OOT patches were required (both at LLVM and at Kernel sides)?

LLVM 8.0.0 released

ncultra — Wed, 20 Mar 2019 16:06:49 +0000

thank you, I do wish I could use clang and this feature in particular on my current project, which is not yet ready to branch away from gcc.

LLVM 8.0.0 released

nybble41 — Wed, 20 Mar 2019 15:15:11 +0000

I think they meant that branching over the declaration of a variable and then using the uninitialized value should be a hard-error, not that Duff's device should be a hard-error in general. Keep in mind that the situations this change was meant to address already involve undefined behavior. Duff's device should be fine as long as you don't put variable declarations inside the switch statement.

LLVM 8.0.0 released

ncultra — Wed, 20 Mar 2019 14:51:11 +0000

"Variables declared in unreachable code and used later aren’t initialized. This affects goto statements, Duff’s device, and other objectionable uses of switch statements. This should instead be a hard-error in any serious codebase."

Duff's device a hard-error? Heresy!