|
|
Subscribe / Log in / New account

LLVM 8.0.0 released

LLVM 8.0.0 released

Posted Mar 20, 2019 14:51 UTC (Wed) by ncultra (✭ supporter ✭, #121511)
Parent article: LLVM 8.0.0 released

"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!


to post comments

LLVM 8.0.0 released

Posted Mar 20, 2019 15:15 UTC (Wed) by nybble41 (subscriber, #55106) [Link] (3 responses)

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

Posted Mar 20, 2019 16:06 UTC (Wed) by ncultra (✭ supporter ✭, #121511) [Link] (2 responses)

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

Posted Mar 21, 2019 4:41 UTC (Thu) by wahern (subscriber, #37304) [Link] (1 responses)

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

Posted Mar 21, 2019 12:42 UTC (Thu) by ncultra (✭ supporter ✭, #121511) [Link]

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.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds