# compilers Published articles for compilers. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Keleusma Research Spike: What Happens When Error Correction Meets a Signature DevFeed: [Keleusma Research Spike: What Happens When Error Correction Meets a Signature]() Original publisher: [Read original article]() Author: Brendan Sechter Published: 2026-08-10T09:00:00Z Content type: article Language: en Sources: [Brendan A R Sechter's Development Blog]() Topics: [Security, Privacy and Abuse Prevention](), [Cryptography](), [Code](), [Compiler]() Tags: [bytecode](), [compiler](), [compilers](), [cryptographic](), [engineering](), [integrity](), [research](), [security](), [test](), [verification]() ### AI overview This case study examines how combining error correction with cryptographic signatures can create an unsafe verification order. Exhaustive analysis of bit errors shows that some damaged inputs are incorrectly repaired or reported as clean, so a clean correction result does not establish integrity. ### Source excerpt A file carries an error-correcting code so that a flipped bit can be repaired, and a cryptographic signature so that a changed byte is refused. Both are ordinary. Putting them in the same file forces a choice that neither feature announces, and one of the two answers is sound only under an assumption that the error-correcting code exists because it is false. The uncomfortable part is that the two answers are indistinguishable on every input anybody tests. An undamaged file behaves identically under both. They diverge only on damaged input, and damaged input is the case the error-correcting code exists for and the case no test suite exercises, because producing it requires deliberately corrupting your own artefact. Enumerating the fault space of a single 64-bit word exhaustively, rather than sampling it, gives four numbers that decide the design. The space is small enough to enumerate because the number of ways to flip $w$ bits out of 64 is a binomial coefficient, and for $w \le 4$ it stays under a million. \[\binom{64}{1} = 64, \quad \binom{64}{2} = 2{,}016, \quad \binom{64}{3} = 41{,}664, \quad \binom{64}{4} = 635{,}376\] flipped bits patterns repaired exactly wrongly "repaired" invisible 1 64 64 0 0 2 2,016 0 0 0 3 41,664 0 23,364 (56.08%) 0 4 635,376 0 0 5,133 (0.81%) Three flipped bits are reported as a successful repair 56.08 percent of the time, and the repair is wrong every time it happens. Four flipped bits are, 5,133 times, completely invisible, because the code reports the word as clean when the error pattern is itself a valid codeword. The consequence is one sentence, and everything else in this article is either its derivation or its implications. The corrector is not an authority on whether it corrected, and a clean report from it is not evidence of integrity. What this is a case study of The setting is the bytecode format for Keleusma, a language whose value proposition is that a program's worst-case time and memory can be proven before it runs, and wh ## Keleusma Research Spike: What It Costs to Compile a Data Structure Whose Shape Is Already Decided DevFeed: [Keleusma Research Spike: What It Costs to Compile a Data Structure Whose Shape Is Already Decided]() Original publisher: [Read original article]() Author: Brendan Sechter Published: 2026-08-09T09:00:00Z Content type: article Language: en Sources: [Brendan A R Sechter's Development Blog]() Topics: [Compiler](), [Back end](), [Data structures]() Tags: [arrays](), [case-study](), [compiler](), [compilers](), [data-structure](), [engineering](), [research](), [verification]() ### AI overview This case study examines the cost of compiling aggregate data types in the Keleusma compiler backend. Measurements of 331 aggregate operations found that most reduce to constant offsets and typed loads, challenging an estimate based on the feature's general name rather than its actual instances. ### Source excerpt The largest remaining item in a compiler backend was estimated at a quarter's work. Measured, it is pointer arithmetic over compile-time constants, and two of the three representation forms it was supposed to need account for two operations in the entire corpus. The item is aggregate data types, meaning structs, tuples, arrays and enumerations. It blocks 34.5 percent of the corpus, more than every other unimplemented feature combined, and it had never been scoped because everyone knew it was large. Everyone was reasoning from the wrong artefact. Aggregates are large in a compiler that must decide their layout. This compiler decided it already, in an earlier pass, and bakes the answer into the instruction stream. What reaches the backend is not a type system. It is a byte offset and a scalar kind. The measurement that establishes this took twenty minutes to write and two and a half seconds to run. It reports that of 331 aggregate operations in the corpus, 300 are a constant offset and a typed load, 2 need anything resembling a value representation, and 0 use the general mechanism the instruction set still carries. This article reports that, and reports why the author's own recommendation to run it deserves more scepticism than the result. What this is a case study of The setting is compiler backend scoping and the project is Keleusma, whose backend is described in the first, second and third articles of this series. No compiler background is required. The general shape is estimating the cost of a feature from its name rather than from its instances. "Aggregate data types" names something with a large literature, a hard general case, and a well-known set of representation decisions. None of that is evidence about the work in front of you, and the gap between the category and the instance is where the estimate went wrong. The transferable question is what remains once a decision has already been made upstream. The answer is often mechanical, and the mechanical residue ## Do Verified Memory Bounds Survive Compilation? DevFeed: [Do Verified Memory Bounds Survive Compilation?]() Original publisher: [Read original article]() Author: Brendan Sechter Published: 2026-08-08T09:00:00Z Content type: article Language: en Sources: [Brendan A R Sechter's Development Blog]() Topics: [Compiler]() Tags: [compiler](), [compilers](), [engineering](), [verification]() ### AI overview This case study examines whether a verified memory bound remains applicable after compilation. An erratum corrects earlier measurements: on the measured corpus and shipped pipeline, the proven bound was empirically conservative, but this does not establish soundness because the bound and compiled frame measure different quantities. ### Source excerpt Erratum, 2026-08-12 The empirical sections of this article measured code that had never been optimised, and the corrected figures reverse the direction of the finding. The measurement invoked the back end at two optimisation levels over the same intermediate representation. The pass that promotes stack slots into registers is a middle-end pass and the back end does not run it, so both figures described unpromoted code and the difference between them was back-end noise. Three claims made below are wrong and are corrected in place, with the original figures retained so the change is visible. The optimiser eliminates the provisioning, and does not relocate it into spill slots. Promoted then lowered, the same 19 modules occupy 5,048 bytes of frame against the 275,432 bytes reported here for unpromoted code, a factor of 54. The proven bound exceeds the real frame in every module measured, rather than falling short of it. The ratios run from 0.12 to 0.88. The article's claim that this fails in the dangerous direction is the reverse of what happens. The provisioning change reported elsewhere as a large saving buys nothing for the shipped pipeline, since promotion had already removed the dead allocations. This does not rescue the bound. Eight modules agree that it exceeds the frame and no mechanism guarantees that. The two quantities are in different units, count different things and are decided by different agents, so the agreement is coincidence and not construction. The supportable statement is that the bound is empirically conservative on this corpus under the shipped pipeline, which is much weaker than sound. The structural contribution is unaffected, being the three-part split of the bound set out in Result 1, the literature survey, and the timing result with its stated weakness. Somebody proves a program can never use more than a certain amount of memory. Then a compiler rewrites that program into a different form before it runs. Does the proof still apply? The answe ## Why Two Similar Compiler Cases Cannot Share One Calling Convention DevFeed: [Why Two Similar Compiler Cases Cannot Share One Calling Convention]() Original publisher: [Read original article]() Author: Brendan Sechter Published: 2026-08-07T09:00:00Z Content type: article Language: en Sources: [Brendan A R Sechter's Development Blog]() Topics: [Compiler](), [interface](), [Back end](), [test](), [Mathematics]() Tags: [article](), [backend](), [case-study](), [class](), [compiler](), [compilers](), [engineering](), [interface](), [mathematics](), [measurement](), [verification]() ### AI overview This compiler backend case study argues that two similar cases cannot be unified when one must report two values through an interface with only one available slot. A counting argument shows that the apparent similarity of nine measured occurrences is irrelevant to the shared interface design. The article also identifies an earlier rule that unnecessarily excluded ten of twenty-four cases. ### Source excerpt A system had grown two ways of doing what looked like one thing. The obvious move was to tidy them into one. The tidying turns out to be impossible, and the reason it is impossible is the reason the two ways exist. The argument that settles it needs no specialist knowledge and fits in a sentence. One of the two cases has two things to report and only one slot to report them in. Whichever thing the slot is given, the other is lost. The other case has only one thing to report, so the single slot is exactly enough. That is a counting argument, it is decided before any code is written, and it is not the argument an engineer reaches for by default. The engineer's instinct is to look at the cases and ask whether they resemble one another. They did. Every one of the nine measured occurrences had exactly the shape that invited the tidy-up, and the measurement encouraged precisely the wrong conclusion. The resemblance was real and it was irrelevant, because the defect was never in the instances. It was in the interface they would have had to share. This article is about that distinction, which is between evidence about members of a class and evidence about the channel the class must pass through. The second dominates the first and is cheaper to check. The article reports the measurement, the way the measurement pointed the wrong direction, and the argument that settled it. It also reports a rule this author shipped one increment earlier which turns out to be stricter than the property it enforces, excluding ten of twenty-four cases for no reason. No test found that. It surfaced while gathering data for this article. How to read this The general argument is in the opening, in the section called The Argument That Settled It, and in Pattern Extraction. Those three need nothing but attention. The sections between them work the argument through a real case with real numbers, and they use the vocabulary of the trade. Every term is glossed at first use, but a reader who wants the r ## Keleusma Research Spike: Blocking Frequency as the Ordering Principle for Instruction-Set Coverage DevFeed: [Keleusma Research Spike: Blocking Frequency as the Ordering Principle for Instruction-Set Coverage]() Original publisher: [Read original article]() Author: Brendan Sechter Published: 2026-08-06T09:00:00Z Content type: article Language: en Sources: [Brendan A R Sechter's Development Blog]() Topics: [Compiler](), [Code generation](), [Code]() Tags: [article](), [code-generation](), [compiler](), [compilers](), [engineering](), [measurement](), [ordering](), [research](), [verification]() ### AI overview This case study examines how blocking frequency can guide the order of instruction implementation in Keleusma's compiler backend. It contrasts instruction-level coverage with whole-program compilability and describes a small measurement tool that exposed a flawed implementation plan. ### Source excerpt A compiler was 87 percent finished. It could not compile two thirds of the programs it was for. Both numbers are correct. The first counts individual instructions the compiler knew how to translate. The second counts whole programs that would actually go through. The gap between them is what this article is about, and the reason it exists is simple enough to state in one sentence. A program needs every instruction it uses, not most of them. One missing instruction out of a hundred stops the whole thing, exactly as one missing link stops a chain. That gap then destroyed a carefully reasoned plan. One working session before the measurement was taken, the author of this article had formally recommended what the next piece of work should be. The reasoning had no invalid step in it. The measurement showed the recommendation to be worth nothing at all, because the thing it would have unblocked does not occur even once in any program the compiler is meant to serve. The instrument that established this took about twenty minutes to build and two seconds to run. The article reports that, and then reports four errors made while writing it, all four of which ran in the direction of a more striking result, and one of which was committed inside the paragraph warning against the other three. What this is a case study of The setting is compiler engineering, and a reader who has never written a compiler can follow the argument, because the shape of the problem is not specific to compilers. The concrete project is Keleusma, whose compiler until now has emitted bytecode for a virtual machine, as described in the self-hosting strategy and its getting-started article. Native code generation is the step after that one, and it is where the ordering question first became expensive enough to measure. The lineage of the design sits in the stream-based compilers series and in the self-hosted silicon compiler. None of that background is needed to follow what follows, and the measurement stands ## How to Take an 11 Month Sabbatical DevFeed: [How to Take an 11 Month Sabbatical]() Original publisher: [Read original article]() Author: Zac Sweers Published: 2026-06-29T05:54:30Z Content type: opinion Language: en Sources: [Zac Sweers]() Topics: [Programming](), [Slack](), [compilers](), [Algorithms, Complexity]() Tags: [2025](), [algorithms](), [compilers](), [slack](), [work]() ### AI overview The author reflects on leaving Slack after nearly six years to take an 11-month sabbatical. During the break, they focused on running, open-source work on Metro, fostering dogs, travel, and revisiting subjects such as compilers and algorithms through practical projects. ### Source excerpt A sequel to the last one, but a bit longer. On Leaving Slack After nearly 6 years, I left Slack in August of 2025. It was for a combination of reasons that added up to "it's time". The biggest reason was that Salesforce (who acquired Slack ## OpenCL 3.1 is Here DevFeed: [OpenCL 3.1 is Here]() Original publisher: [Read original article]() Author: Khronos Group (webservices@khronosgroup.org) Published: 2026-05-04T07:01:00Z Content type: release Language: en Sources: [Blogs Khronos Blog]() Topics: [cross-platform](), [Compiler](), [Open Source](), [toolchain]() Tags: [2026](), [api](), [blog-openc](), [compilation](), [compiler](), [compilers](), [cross-platform](), [directx](), [embedded](), [enumerate](), [opencl](), [optional](), [source](), [spir](), [vulkan]() ### AI overview The Khronos OpenCL Working Group has released OpenCL 3.1, moving field-proven capabilities into the core specification. The release mandates SPIR-V kernel ingestion for conformant implementations and expands cross-platform availability through a growing implementation, compiler, runtime, and framework ecosystem. ### Source excerpt On the eve of IWOCL 2026, the Khronos® OpenCL Working Group has released OpenCL™ 3.1, bringing widely deployed, field-proven capabilities into the core specification to expand functionality, including SPIR-V ingestion, that developers will be able to rely on across conformant implementations. The new specification arrives into a growing OpenCL ecosystem, with implementations from multiple silicon vendors, particularly in mobile and embedded markets, and higher-level frameworks including SYCL™ and chipStar increasingly targeting OpenCL as an acceleration backend. The open-source compiler and runtime ecosystem around OpenCL also continues to mature with layered implementations of OpenCL over Vulkan and DirectX 12 -- widening OpenCL's cross-platform availability, including on platforms without native drivers. ## Wastrel Compiles Hoot Scheme-to-WebAssembly Output DevFeed: [Wastrel Compiles Hoot Scheme-to-WebAssembly Output]() Original publisher: [Read original article]() Author: Andy Wingo Published: 2026-03-31T20:34:23Z Content type: article Language: en Sources: [wingolog]() Topics: [WebAssembly](), [Compiler](), [scheme]() Tags: [accidentally-quadratic](), [aot](), [bigint](), [bignums](), [compiler](), [compilers](), [exception-handling](), [exceptions](), [gc](), [gcc](), [gmp](), [hoot](), [igalia](), [library](), [maps](), [precision](), [scheme](), [standard](), [tail-calls](), [wasm](), [wastrel](), [webassembly](), [whippet]() ### AI overview The article describes recent work on Wastrel, an ahead-of-time WebAssembly compiler, including compiling output from the Hoot Scheme-to-Wasm compiler. It covers implementing bignum operations with mini-gmp and updating Hoot to use standardized WebAssembly exception handling. ### Source excerpt Good day! Today (tonight), some notes on the last couple months of Wastrel, my ahead-of-time WebAssembly compiler. Back in the beginning of February, I showed Wastrel running programs that use garbage collection, using an embedded copy of the Whippet collector, specialized to the types present in the Wasm program. But, the two synthetic GC-using programs I tested on were just ported microbenchmarks, and didn't reflect the output of any real toolchain. In this cycle I worked on compiling the output from the Hoot Scheme-to-Wasm compiler. There were some interesting challenges! bignums When I originally wrote the Hoot compiler, it targetted the browser, which already has a bignum implementation in the form of BigInt, which I worked on back in the day. Hoot-generated Wasm files use host bigints via externref (though wrapped in structs to allow for hashing and identity). In Wastrel, then, I implemented the imports that implement bignum operations: addition, multiplication, and so on. I did so using mini-gmp, a stripped-down implementation of the workhorse GNU multi-precision library. At some point if bignums become important, this gives me the option to link to the full GMP instead. Bignums were the first managed data type in Wastrel that wasn't defined as part of the Wasm module itself, instead hiding behind externref, so I had to add a facility to allocate type codes to these "host" data types. More types will come in time: weak maps, ephemerons, and so on. I think bignums would be a great proposal for the Wasm standard, similar to stringref ideally (sniff!), possibly in an attenuated form. exception handling Hoot used to emit a pre-standardization form of exception handling, and hadn't gotten around to updating to the newer version that was standardized last July. I updated Hoot to emit the newer kind of exceptions, as it was easier to implement them in Wastrel that way. Some of the problems Chris Fallin contended with in Wasmtime don't apply in the Wastrel case: sinc ## Long branches in compilers, assemblers, and linkers DevFeed: [Long branches in compilers, assemblers, and linkers]() Original publisher: [Read original article]() Published: 2026-01-25T08:00:00Z Content type: article Language: en Sources: [MaskRay]() Topics: [toolchain](), [Compiler](), [Assembly]() Tags: [architectures](), [article](), [assembler](), [binutils](), [compilers](), [implementation](), [linker](), [llvm](), [toolchain]() ### AI overview This article explains how compilers, assemblers, and linkers handle branch instructions whose PC-relative targets exceed the supported range. It describes the division of responsibility across toolchain stages and compares branch-range limitations across architectures, including AArch32, AArch64, and LoongArch. ### Source excerpt Branch instructions on most architectures use PC-relative addressing with a limited range. When the target is too far away, the branch becomes "out of range" and requires special handling. Consider a large binary where main() at address 0x10000 calls foo() at address 0x8010000-over 128MiB away. On AArch64, the bl instruction can only reach ±128MiB, so this call cannot be encoded directly. Without proper handling, the linker would fail with an error like "relocation out of range." The toolchain must handle this transparently to produce correct executables. This article explores how compilers, assemblers, and linkers work together to solve the long branch problem. Compiler (IR to assembly): Handles branches within a function that exceed the range of conditional branch instructions Assembler (assembly to relocatable file): Handles branches within a section where the distance is known at assembly time Linker: Handles cross-section and cross-object branches discovered during final layout ## A Practical guide to building a parser in Go DevFeed: [A Practical guide to building a parser in Go]() Original publisher: [Read original article]() Author: Tom Published: 2026-01-04T00:00:00Z Content type: tutorial Language: en Sources: [Tomasz Gągor]() Topics: [Go Language](), [Parser](), [Programming](), [Programming language]() Tags: [bnf](), [compilers](), [dsl](), [go](), [guide](), [left-recursion](), [lexer](), [packrat-memoization](), [parsing](), [programming](), [recursive-descent-parser]() ### AI overview A developer describes building a recursive descent parser in Go to validate strings against a BNF-like grammar. The project began as an attempt to implement a simple BNF syntax analyzer and led to exploring parser and compiler concepts, including left recursion and Packrat memoization. ### Source excerpt A developer's journey of building a recursive descent parser in Go, from basic concepts to tackling left recursion with Packrat memoization. ## Good technology blogs: a reading list for the holidays DevFeed: [Good technology blogs: a reading list for the holidays]() Original publisher: [Read original article]() Author: Alexey Milovidov Published: 2025-12-29T00:00:00Z Content type: article Language: en Sources: [ClickHouse Blog]() Topics: [Programming](), [Algorithms, Complexity](), [Data structures](), [Databases](), [Computer science](), [Parsing](), [systems](), [Networks](), [Web Development](), [Artificial Intelligence]() Tags: [blog](), [compilers](), [data-structures](), [databases](), [hardware](), [networks](), [performance](), [programming](), [systems](), [web-development]() ### AI overview A holiday reading list of favorite technology blogs covering performance optimization, data structures and algorithms, database development, compilers, operating systems, programming languages, computer science, mathematics, hardware, networks, web development, computer graphics, and AI. It highlights authors and libraries connected to high-performance software and ClickHouse, including simdjson, Roaring bitmap, USearch, StringZilla, Hyperscan, Miniselect, LZ4, and zstd. ### Source excerpt A collection of my favorite technology blogs ## Java Hello World, LLVM Edition DevFeed: [Java Hello World, LLVM Edition]() Original publisher: [Read original article]() Author: James Hamilton Published: 2025-12-07T02:02:37Z Content type: tutorial Language: en Sources: [Java Advent Calendar]() Topics: [Java](), [LLVM](), [API](), [JIT]() Tags: [2025](), [api](), [assembly](), [bytecode](), [compilers](), [java](), [java-advent](), [jdk](), [jit](), [jvm](), [llvm]() ### AI overview This tutorial shows how to use Java's Foreign Function & Memory API to call the LLVM C API, generate LLVM IR for a Hello World program, and JIT-compile it to native code. It also introduces LLVM, its IR representations, and local installation on Ubuntu or Debian. ### Source excerpt After exploring Java bytecode in previous years (2022, 2023, 2024), this year we'll take an unexpected detour for a Java advent: instead of generating Java bytecode, we'll use Java to build and execute LLVM IR, the intermediate language behind compilers like clang. Using Java's Foreign Function & Memory (FFM) API, we'll call the LLVM C [...] The post Java Hello World, LLVM Edition appeared first on JVM Advent. ## NixOS 25.11 released DevFeed: [NixOS 25.11 released]() Original publisher: [Read original article]() Author: NixOS Published: 2025-11-30T16:00:00Z Content type: release Language: en Sources: [NixOS Announcements]() Topics: [Nix](), [Linux](), [Release notes](), [version](), [configuration](), [modules](), [CMake](), [gcc](), [LLVM]() Tags: [2026](), [bugfixes](), [cmake](), [compilers](), [deprecated](), [end-of-life](), [gcc](), [linux](), [llvm](), [nix](), [nixos](), [nixpkgs](), [release](), [release-notes](), [version]() ### AI overview NixOS 25.11 "Xantusia" is publicly available. The release updates Nixpkgs with new, updated, and removed packages; adds configuration modules and options; updates GNOME to version 49, LLVM to version 21, and CMake to version 4; and provides bugfix and security updates through June 30, 2026. ### Source excerpt Hey everyone, we are jopejoe1 and Leona Maroni, the release managers of the newest release of NixOS. We are very proud to announce the public availability of NixOS 25.11 "Xantusia". NixOS is a Linux distribution. Its underlying package repository Nixpkgs can also be used on other Linux systems and macOS with the Nix package manager. This release will receive bugfixes and security updates for seven months (up until 2026-06-30). The old release 25.05 "Warbler" is now officially deprecated and will reach its end-of-life and stop receiving security updates after 2025-12-31. NixOS Release Notes Highlights New Modules Backward Incompatibilities Other Notable Changes Nixpkgs Release Notes Highlights Backward Incompatibilities Other Notable Changes Nixpkgs Library Upgrade Instructions ISO Image Downloads The 25.11 release was made possible due to the efforts of 2742 contributors, who authored 59430 commits since the previous release. Highlights Our vast and routinely maintained set of packages has also been updated. This release of Nixpkgs Added 7002 new packages Updated 25252 existing packages Removed 6338 outdated packages, in an effort to keep the package set maintainable and secure. In addition to packages from Nixpkgs, the NixOS Linux distribution also features composable configuration modules and integration tests for distributed systems. This release of NixOS Added 107 new modules and 1778 configuration options Removed 41 outdated modules and 807 configuration options. GNOME 49 GNOME has been updated to version 49 "Brescia", which removes X11 session support, introduces a new video player, a new document viewer, a redesigned calendar and more changes. Refer to the release notes for more details. C compilers LLVM has been updated to version 21. GCC remains at version 14. CMake was updated to version 4. Special Thanks We want to personally thank Seth and dish for editorializing the release notes Yohann Boniface for the release logo The NixOS infrastructure team for the ## Integer Set Library (ISL) - A Primer DevFeed: [Integer Set Library (ISL) - A Primer]() Original publisher: [Read original article]() Published: 2025-10-19T20:14:22Z Content type: tutorial Language: en Sources: [Jeremy Kun]() Topics: [Library](), [Optimization](), [compilers](), [Open Source](), [mlir]() Tags: [code](), [compilers](), [isl](), [library](), [loops](), [mathematics](), [mlir](), [open-source](), [optimization](), [polyhedral-optimization](), [programming](), [set-theory]() ### AI overview This primer introduces the Integer Set Library (ISL), an open-source C library that implements core algorithms for polyhedral optimization. It focuses on representing integer sets and relations, manipulating them, and the relationship between ISL and MLIR's Fast Presburger Library. ### Source excerpt Polyhedral optimization is a tool used in compilers for optimizing loop nests. While the major compilers that use this implement polyhedral optimizations from scratch,1 there is a generally-applicable open source C library called the Integer Set Library (ISL) that implements the core algorithms used in polyhedral optimization. This article gives an overview of a subset of ISL, mainly focusing on the representation of sets and relations and basic manipulations on them. ## NixOS 25.05 released DevFeed: [NixOS 25.05 released]() Original publisher: [Read original article]() Author: NixOS Published: 2025-05-23T12:00:00Z Content type: release Language: en Sources: [NixOS Announcements]() Topics: [Nix](), [Release notes](), [releases](), [Linux](), [configuration](), [modules](), [Linux Kernel](), [distributed-systems](), [gcc](), [LLVM](), [upgrade]() Tags: [bugfixes](), [compilers](), [deprecated](), [end-of-life](), [features](), [gcc](), [kernel](), [linux](), [linux-kernel](), [llvm](), [nix](), [nixos](), [release](), [release-notes](), [updated](), [updates](), [version]() ### AI overview NixOS 25.05, codenamed "Warbler," is publicly available. The release adds and updates packages, introduces configuration modules and options, updates GNOME and the default Linux kernel, and updates LLVM and GCC. NixOS 25.05 receives bugfixes and security updates through 2025-12-31, while NixOS 24.11 reaches end of life after 2025-06-30. ### Source excerpt Hey everyone, we are Leona Maroni and Tristan Ross, the release managers of the newest release of NixOS. We are very proud to announce the public availability of NixOS 25.05 "Warbler". NixOS is a Linux distribution. Its underlying package repository Nixpkgs can also be used on other Linux systems and macOS with the Nix package manager. This release will receive bugfixes and security updates for seven months (up until 2025-12-31). The old release 24.11 "Vicuña" is now officially deprecated and will reach its end-of-life and stop receiving security updates after 2025-06-30. NixOS Release Notes Highlights New Services Backward Incompatibilities Other Notable Changes Nixpkgs Release Notes Highlights Backward Incompatibilities Other Notable Changes Nixpkgs Library Upgrade Instructions ISO Image Downloads The 25.05 release was made possible due to the efforts of 2857 contributors, who authored 57054 commits since the previous release. Highlights NixOS is already known as the most up to date distribution while also being the distribution with the most packages. This release of Nixpkgs Added 7840 new packages Updated 28054 existing packages Removed 1694 outdated packages, in an effort to keep the package set maintainable and secure. In addition to packages from Nixpkgs, the NixOS Linux distribution also features composable configuration modules and integration tests for distributed systems. This release of NixOS Added 137 new modules and 1930 configuration options Removed 10 outdated modules and 215 configuration options. GNOME 48 GNOME has been updated to version 48 "Bengaluru", which introduces notification stacking, a new music player, HDR support, and more changes. Refer to the release notes for more details. Kernel The default Linux kernel has been updated from 6.6 to 6.12. All supported kernels remain available. C compilers LLVM has been updated to version 19. GCC has been updated to version 14. Special Thanks We want to personally thank Seth and raf for editorializin ## Demonstrably Secure Software Supply Chains with Nix DevFeed: [Demonstrably Secure Software Supply Chains with Nix]() Original publisher: [Read original article]() Author: Jacek Galowicz Published: 2025-05-12T00:00:00Z Content type: article Language: en Sources: [Nixcademy Blog]() Topics: [Nix](), [supply-chain-security](), [open-source-security](), [integrity](), [Security](), [toolchains](), [audit]() Tags: [audit](), [audits](), [builds](), [capabilities](), [compilers](), [compliance](), [environments](), [government](), [integrity](), [local](), [offline](), [organizations](), [rebuilds](), [secure-software](), [security](), [software](), [software-supply-chain](), [software-supply-chain-security](), [supply-chain](), [supply-chain-security]() ### AI overview This article explains how Nix can support verifiable software supply chain integrity. It describes tracing sources and toolchains, enabling hermetic offline rebuilds, and exporting release sources for audits to help meet regulatory requirements. ### Source excerpt Discover how Nix can revolutionize your software supply chain security, enabling verifiable integrity and offline rebuilds from source. ## Performance of the Python 3.14 tail-call interpreter DevFeed: [Performance of the Python 3.14 tail-call interpreter]() Original publisher: [Read original article]() Author: Nelson Elhage Published: 2025-03-09T22:00:00Z Content type: article Language: en Sources: [Nelson Elhage]() Topics: [Python 3.14](), [benchmarking](), [gcc](), [LLVM](), [Software Engineering]() Tags: [benchmark](), [benchmarking](), [benchmarks](), [bytecode](), [clang](), [compilers](), [cpu](), [gcc](), [intel](), [llvm](), [performance](), [performance-engineering](), [python](), [python-3-14](), [software-engineering]() ### AI overview This article examines the performance gains attributed to CPython's Python 3.14 tail-call bytecode interpreter. It finds that the initial 10-15% improvement was primarily caused by inadvertently working around an LLVM 19 regression; with better baselines, the gain is closer to 1-5%, depending on the setup. ### Source excerpt About a month ago, the CPython project merged a new implementation strategy for their bytecode interpreter. The initial headline results were very impressive, showing a 10-15% performance improvement on average across a wide range of benchmarks across a variety of platforms. Unfortunately, as I will document in this post, these impressive performance gains turned out to be primarily due to inadvertently working around a regression in LLVM 19. When benchmarked against a better baseline (such GCC, clang-18, or LLVM 19 with certain tuning flags), the performance gain drops to 1-5% or so depending on the exact setup. ## Converting Between Packings in SIMD-Style FHE DevFeed: [Converting Between Packings in SIMD-Style FHE]() Original publisher: [Read original article]() Published: 2024-09-02T21:01:03Z Content type: tutorial Language: en Sources: [Jeremy Kun]() Topics: [FHE](), [homomorphic encryption](), [data](), [Code]() Tags: [compilers](), [encryption](), [fhe](), [github](), [graph-coloring](), [heir](), [homomorphic-encryption](), [mathematics](), [optimization](), [packing](), [permutation](), [programming](), [rlwe](), [simd]() ### AI overview This article explains packing in SIMD-style fully homomorphic encryption and focuses on converting between established packings. It introduces a computational model involving RLWE ciphertext vectors, elementwise operations, cyclic rotations, and differing operation costs. ### Source excerpt In my recent overview of homomorphic encryption, I underemphasized the importance of data layout when working with arithmetic (SIMD-style) homomorphic encryption schemes. In the FHE world, the name given to data layout strategies is called "packing," because it revolves around putting multiple plaintext data into RLWE ciphertexts in carefully-chosen ways that mesh well with the operations you'd like to perform. By "mesh well" I mean it reduces the number of extra multiplications and rotations required merely to align data elements properly, rather than doing the actual computation you care about. ## MLIR -- Defining Patterns with PDLL DevFeed: [MLIR -- Defining Patterns with PDLL]() Original publisher: [Read original article]() Published: 2024-08-04T14:00:00Z Content type: tutorial Language: en Sources: [Jeremy Kun]() Topics: [LLVM](), [Tooling]() Tags: [c-plus-plus](), [compilers](), [heir](), [llvm](), [mathematics](), [mlir](), [optimization](), [patterns](), [primer](), [programming](), [tablegen]() ### AI overview A tutorial on using PDLL to define MLIR patterns. It explains PDLL's relationship to PDL, its intended role as an alternative to TableGen pattern definitions, and how PDLL files are transformed into IR and then C++ code for compilation into a pass. ### Source excerpt Table of Contents In this article I'll show how to use PDLL, a tool for defining MLIR patterns, which itself is built with MLIR. PDLL is intended to be a replacement for defining patterns in tablegen, though there are few public examples of its use. In fact, the main impetus for PDLL is that tablegen makes it difficult to express things like: Operations that return multiple results Operations with regions Operations with variadic operands Arithmetic on static values While not all these features are fully supported in PDLL yet, they are within scope of the language and tooling. ## Static Code Analysers DevFeed: [Static Code Analysers]() Original publisher: [Read original article]() Published: 2024-01-22T00:15:00Z Content type: tutorial Language: en Sources: [Kt. Academy]() Topics: [detekt](), [Kotlin](), [Programming](), [code reviews](), [compilers]() Tags: [android](), [code-reviews](), [compilers](), [detekt](), [generics](), [java](), [jvm](), [kotlin](), [workshop-learning-programming]() ### AI overview This tutorial introduces static analysis as a way to identify bugs and recurring code patterns without running the code. It explains how static analysers can automate and enforce coding patterns in large Kotlin codebases, then begins a practical walkthrough of detekt, a popular Kotlin static analyser. ### Source excerpt All you need to know about Static Code Analysers and Detekt. ## 30 Years of Decompilation and the Unsolved Structuring Problem: Part 2 DevFeed: [30 Years of Decompilation and the Unsolved Structuring Problem: Part 2]() Original publisher: [Read original article]() Published: 2024-01-10T00:00:00Z Content type: article Language: en Sources: [mahaloz.re]() Topics: [Programming](), [compilers](), [phoenix]() Tags: [compilers](), [deep-dive](), [ida](), [ida-pro](), [phoenix](), [research](), [security](), [technical]() ### AI overview Part 2 of a history of decompiler research examines modern control-flow structuring techniques, their limitations, and possible future directions. It reviews four papers from the past 11 years, including Phoenix, and places them in the context of security, compiler, static-analysis, and programming-language research. ### Source excerpt A two-part series on the history of decompiler research and the fight against the unsolved control flow structuring problem. In part 1, we revisit the history of foundational decompilers and techniques, concluding on a look at modern works. In part 2, we deep-dive into the fundamentals of modern control flow structuring techniques, and their limitations, and look to the future. ## MLIR -- A Global Optimization and Dataflow Analysis DevFeed: [MLIR -- A Global Optimization and Dataflow Analysis]() Original publisher: [Read original article]() Published: 2023-11-15T11:20:52Z Content type: article Language: en Sources: [Jeremy Kun]() Topics: [Optimization](), [Code](), [Framework]() Tags: [analysis](), [code](), [compilers](), [framework](), [heir](), [mathematics](), [mlir](), [optimization](), [primer](), [programming](), [pull-request]() ### AI overview This article explains how to implement a global optimization pass in MLIR for noisy integer arithmetic. It uses a dataflow analysis framework to verify the optimization and aims to keep noise within legal limits while minimizing program cost. ### Source excerpt Table of Contents In this article we'll implement a global optimization pass, and show how to use the dataflow analysis framework to verify the results of our optimization. The code for this article is in this pull request, and as usual the commits are organized to be read in order. The noisy arithmetic problem This demonstration is based on a simplified model of computation relevant to the HEIR project. You don't need to be familiar with that project to follow this article, but if you're wondering why someone would ever want the kind of optimization I'm going to write, that project is why. ## Why Do Peephole Optimizations Work? DevFeed: [Why Do Peephole Optimizations Work?]() Original publisher: [Read original article]() Author: regehr Published: 2023-11-01T16:23:20Z Content type: article Language: en Sources: [Embedded in Academia]() Topics: [Optimization](), [compilers](), [LLVM](), [Code]() Tags: [code](), [compilers](), [execution](), [llvm](), [optimization](), [reduce](), [uncategorized]() ### AI overview The article explains why peephole optimizations work in modern compilers. It contrasts local instruction rewrites with transformations over SSA-based intermediate representations and discusses correctness in terms of observable behavior and refinement. ### Source excerpt In its original form, a peephole optimization applied to a collection of instructions located close together in a program. For example, in a register transfer language we might find this sequence of instructions: r0 = xor r8, -1 r1 = xor r9, -1 r0 = and r0, r1 Here, assuming the two's complement representation, -1 [...] ## MLIR -- Lowering through LLVM DevFeed: [MLIR -- Lowering through LLVM]() Original publisher: [Read original article]() Published: 2023-11-01T07:00:00Z Content type: tutorial Language: en Sources: [Jeremy Kun]() Topics: [mlir](), [LLVM](), [x86]() Tags: [compilers](), [heir](), [llvm](), [mathematics](), [mlir](), [pipeline](), [primer](), [programming](), [x86]() ### AI overview A tutorial on lowering a custom MLIR poly dialect through the LLVM dialect, exporting LLVM IR, and compiling it to x86 machine code. It explains how to construct and incrementally develop MLIR lowering pipelines. ### Source excerpt Table of Contents In the last article we lowered our custom poly dialect to standard MLIR dialects. In this article we'll continue lowering it to LLVM IR, exporting it out of MLIR to LLVM, and then compiling to x86 machine code. The code for this article is in this pull request, and as usual the commits are organized to be read in order. Defining a Pipeline The first step in lowering to machine code is to lower to an "exit dialect. [Next page]()