0.12 prg26 2026-10-02 2026-10-04 3 00:05 https://conf.gnu-tools-cauldron.org Europe/Prague Refectory (S 120) Talk 2026-10-02T09:00:00+02:00 09:00 01:00 This talks briefly covers several (mostly random) things I worked on in the middle end this year: - Demand-bit backpropagation - Reassociation of plus/mult trees - Assumptions for unsigned scalar evolution - Dependent register constraints - Vector predicate RTL representation The first two originated in a small, mostly stupid benchmark snippet but turned out to have real value. Unsigned assumptions help vectorizing SPECint 2016's xz. Dependent register constraints and the vector predicate RTL representation help riscv in particular. prg26-103804-demand-bits-scev-assumptions-and-other-fun Robin Dapp en false https://conf.gnu-tools-cauldron.org/prg26/talk/MHWKXJ/ https://conf.gnu-tools-cauldron.org/prg26/talk/MHWKXJ/feedback/ Refectory (S 120) Talk 2026-10-02T10:30:00+02:00 10:30 01:00 This session covers some recent experiments with the `malloc` implementation of the GNU C Library to improve performance and memory usage. The glibc allocator is somewhat unique about widely used allocators: it is not based on extents/spans, but on a modified boundary tag mechanism that colocates allocations of different sizes. There have been multiple efforts of the past year or two to optimize some of this behavior, including: - batching `free`s, with and without sorting deallocations by address - surface-level and deep consolidation of chunks as they are evicted from the thread cache - putting per-thread `malloc` metadata into the thread control block (TCB) - more prompt deallocation of unused heap (64 MiB) segments - using an array for the unsorted bin (instead of a doubly linked list), greatly improving cache locality - replacing the ad-hoc tree for large bin sizes with a proper red-black tree - using linear address masking (LAM) to implement packed 32-byte allocations - optimizing tag management without a dedicated tag manipulation ISA The purpose of this session is to present these experiments and gather feedback what optimizations are most promising and should be submitted for upstream inclusion. prg26-105120-glibc-malloc-experiments-and-future-direction Florian Weimer en We would like to encourage attendees to share their own results and observations. false https://conf.gnu-tools-cauldron.org/prg26/talk/LCFMB9/ https://conf.gnu-tools-cauldron.org/prg26/talk/LCFMB9/feedback/ Refectory (S 120) Talk (Short) 2026-10-02T11:30:00+02:00 11:30 00:30 This presentation covers: - how GCC's Static Analyzer works - progress on C++ support in the Static Analyzer after my GSoC project - future plans for continuing improvements to C++ support. Related writeup can be found at: https://riogu.github.io/posts/gsoc-2026/ prg26-103506-c-support-in-gcc-static-analyzer-progress-and-future-plans Egas Ribeiro en This talk is a mix between covering my GSoC project and sharing it with the community, and talking about the state of the project in general. false Slides for the talk https://conf.gnu-tools-cauldron.org/prg26/talk/CNN8WR/ https://conf.gnu-tools-cauldron.org/prg26/talk/CNN8WR/feedback/ Refectory (S 120) Talk (Short) 2026-10-02T12:00:00+02:00 12:00 00:30 ELF unwind information is encoded as DWARF bytecode for most platforms, which causes a large size overhead and is complex to interpret, precluding its use in e.g. tracing profilers. This talk will present a compact format for asynchronous unwind info that can accurately represent most functions generated by GCC/Clang -O3 for x86-64 with a substantially smaller size (-71% GCC, -87% Clang). The talk will also discuss portability to other architectures (particularly AArch64), differences from other unwinding/tracing formats, and paths forward for adoption. prg26-105311-compact-unwind-information-for-elf-platforms Alexis Engelke en Unwind information is included in almost all executables shared libraries for multiple purposes: in-process stack unwinding for, e.g., C++ exceptions and Rust panics, unwinding in debuggers, and stack tracing, e.g. for profiling or crash information. For the non-exception use cases, unwind information must not only be correct at call sites but needs be accurate at every instruction (asynchronous unwind info). In ELF, unwind information is typically encoded in two sections: .eh_frame, which contains one entry (FDE) per function describing the stack frame layout as a DWARF bytecode program, and .eh_frame_hdr, which contains a binary search table of all functions and their entry in .eh_frame. However, these sections often contribute a considerable size overhead to binaries, typically around 3-7%. Further, the stack frame layout of the functions is often somewhat similar, resulting in a comparably redundant encoding. Additionally, the complexity of the DWARF bytecode adds a substantial cost to stack unwinding and prevents an effective use in time-constrained situations like perf stack tracing. In this talk, we will present a compact unwind information format that substantially reduces the unwind info size while also greatly simplifying stack unwinding and tracing through a more simple format without bytecode. Our current implementation in ld.lld supports x86-64 and can accurately represent almost all (>99%) functions generated by GCC and Clang -O3 (on libLLVM.so) (unsupported functions fall back to DWARF bytecode). This compact representation reduces the size of unwind information (.eh_frame_hdr+.eh_frame) by 71% (GCC -O3)/87% (Clang -O3) without loss of information. In addition to size savings, this format also reduces the cost and worst-case runtime of stack unwinding/tracing and can serve as foundation towards low-overhead profiling with fully accurate call traces, without the performance loss and inaccuracies caused by frame pointers. false https://conf.gnu-tools-cauldron.org/prg26/talk/ACPKEV/ https://conf.gnu-tools-cauldron.org/prg26/talk/ACPKEV/feedback/ Refectory (S 120) Talk 2026-10-02T13:30:00+02:00 13:30 00:45 GCC's rust front end has made great progress this year in multiple areas. We've shifted our focus from compiling the smallest required rust crate to greater goals. The compiler now features the mechanisms required for dynamic memory allocation as well as partial support for RAII mechanisms through the `Drop` trait. This talk will cover the multiple major milestones we've completed this year and will cover the various experiments we made this year toward compiling the rust part of linux using GCC. prg26-105169-gcc-rust-update Pierre-Emmanuel PatryEnes CevikJanet Chien en false https://conf.gnu-tools-cauldron.org/prg26/talk/KDPJHR/ https://conf.gnu-tools-cauldron.org/prg26/talk/KDPJHR/feedback/ Refectory (S 120) Talk 2026-10-02T14:15:00+02:00 14:15 00:45 The upcoming version 6 of DWARF Debugging Information Format specification will bring a major update. In this talk we present a selection of the already-approved or in-queue changes to DWARF that have been proposed by the DWARF-GPU workgroup. In particular - location and storage semantics have been clarified, - locations are now placed and processed in the evaluation stack along with values, - address space information can be expressed in locations and pointer types, - a new operator is proposed to build composite storages by overlaying a location on another location, - call frame information can express locations other than the default memory address space. The talk can be useful for implementors of tools that produce or consume DWARF debug information. prg26-104144-a-gpu-centric-view-of-dwarf-6 Baris Aktemur en false https://conf.gnu-tools-cauldron.org/prg26/talk/VB9NV7/ https://conf.gnu-tools-cauldron.org/prg26/talk/VB9NV7/feedback/ Refectory (S 120) Talk (Short) 2026-10-02T15:00:00+02:00 15:00 00:30 When a developer rebuilds a program after editing its source, GDB re-sets all previously configured breakpoints. Breakpoints set by function name stay put, but breakpoints set with filename:line notation are silently shifted, they land on whatever is now at that line number, not necessarily the code the developer originally intended to stop at. This talk presents a new GDB feature that addresses this problem. When enabled, GDB captures a small window of source lines around each filename:line breakpoint at the time it is set. On the next binary reload, GDB detects the BFD change and searches the updated source file for the same (small) context window. If found, it re-sets the breakpoint at the matched line rather than the original line number. I will show practical examples of the feature in action, discuss its current limitations and share my plans for further improving the feature. prg26-99333-source-tracking-breakpoints-for-gdb alexandra petlanova en I wrote an article about this feature: https://fedoramagazine.org/gdb-source-tracking-breakpoints/ false https://conf.gnu-tools-cauldron.org/prg26/talk/K93GXZ/ https://conf.gnu-tools-cauldron.org/prg26/talk/K93GXZ/feedback/ Refectory (S 120) Talk 2026-10-02T16:00:00+02:00 16:00 01:00 An opportunity for a GNU Toolchain community conversation with the members of the Steering Committees of the GNU Toolchain projects (GCC, GLIBC, Binutils, GDB). prg26-98270-steering-committee-q-a David Edelsohn en false https://conf.gnu-tools-cauldron.org/prg26/talk/A8QUJX/ https://conf.gnu-tools-cauldron.org/prg26/talk/A8QUJX/feedback/ Room S 9 Tutorial 2026-10-02T14:00:00+02:00 14:00 01:30 Ever since the introduction of the first high level programming languages it became necessary to develop techniques to precisely describe their structure (syntax), meaning (semantics) and the way their source constructs are to be used (pragmatics). These specification techniques initially consisted almost entirely in careful but inherently imprecise descriptions written in English or some other natural language, but would quickly evolve to incorporate formal notations (or formalisms), the use of which would prove very beneficial for language designers, implementors and users. In this talk we will go through a historical and more or less detailed exposition of the different techniques used in the specification of programming languages, examining how the introduction of each new formalism and its theoretical background impacted the so-formalized languages. That's the boring part. Very quickly, though, we will focus and immerse into the kind of formalism that is actually practical and has the biggest impact on the programming language and its users: the ones that subdue static semantics into the concrete syntax. Yeah you guessed it: two-level grammars in their van-Wijngaarden and Koster affix flavours. And yeah, you also guessed it: the (in)famous Algol 68 Revised Report and its formalism will be our playground, to the point you will be able to see the Matrix without difficulties or you get your money back. Due to limited time this talk is forced to be somewhat panoramic in nature, but printed handouts with additional material for further study will be distributed beforehand. Previous knowledge on formal languages theory will undoubtly be advantageous to the participant, but it is not absolutely necessary in order to follow and enjoy this talk. prg26-105281-practical-formalization-of-programming-language-semantics Jose Marchesi en false https://conf.gnu-tools-cauldron.org/prg26/talk/XAHX9K/ https://conf.gnu-tools-cauldron.org/prg26/talk/XAHX9K/feedback/ Room S 5 Talk (Short) 2026-10-02T14:00:00+02:00 14:00 00:30 The sourceware forge experiment has now been running for two years. I'll give a brief overview of what's been achieved in that time and then talk about where we want to go next prg26-105101-the-sourceware-forge-experiment-year-2-and-onwards Richard Earnshaw en false https://conf.gnu-tools-cauldron.org/prg26/talk/YZQYFQ/ https://conf.gnu-tools-cauldron.org/prg26/talk/YZQYFQ/feedback/ Room S 5 Birds of a Feather (BoF) 2026-10-02T14:30:00+02:00 14:30 00:30 The ARM Cortex-M0+ processor relies on the 16-bit Thumb instruction set to maximize code density in resource-constrained embedded systems. While the architecture defines sixteen 32-bit registers, standard 16-bit Thumb instructions can only directly address the low registers (R0–R7). We observed Loop Invariant Code Motion makes its decision based on all 16 registers being available. The changes to the code after LICM pass to reduce execution time is ultimately counterproductive as the resulting register pressure forces the allocator to inject costly spill code. prg26-104226-quantifying-register-pressure-16-bit-thumb-constraints-on-standard-optimization-passes Visda Vokhshoori en I will present using a simple C source my analysis on LICM for target Cortex-M0 plus. I will present results comparing Embench built for size and speed with and without this change. false https://conf.gnu-tools-cauldron.org/prg26/talk/MSU8HA/ https://conf.gnu-tools-cauldron.org/prg26/talk/MSU8HA/feedback/ Room S 5 Talk (Short) 2026-10-02T15:00:00+02:00 15:00 00:30 The talk covers optimizing a scheduler cost model in GCC for a RISC-V CPU. During the contribution of a GCC scheduler cost model for the SpacemiT-X60 CPU there was limited information regarding the inner workings of the SpacemiT-X60 publicly available, so there was reverse engineering involved. This talk covers topics which helped in deducing useful values for the scheduling model: * Micro-architectural benchmarks: * Throughput analysis * Gap analysis * Latency analysis * Roofline analysis (cache aware) * Topdown Microarchitectural analysis - TDMA prg26-105317-reverse-engineering-cost-models-for-the-gcc-instruction-scheduler-a-case-study-on-the-bananapi-bpi-f3-risc-v-cpu Dusan Stojkovic en We attempted to devise tests which give a better understanding of how the HW would respond to changes in the scheduler cost model. This means we don’t pick scheduler costs for instructions randomly, rather, initial values are guided by the measurements observed. We showcase the fine-tuning concepts on the scalar and vector cost model of Spacemit-X60 along with an overview of the GCC internal scheduling cost model implementation and how it works. Measurements presented are obtained using the perf Linux C API. We showcase the challenges of using the perf C API to obtain truthful insights into the inner workings of a RISC-V Linux CPU and how by cross-referencing different methods for evaluating micro-architectural performance, sensible values for a GCC scheduler tuning model can be found. false https://conf.gnu-tools-cauldron.org/prg26/talk/BFJEP7/ https://conf.gnu-tools-cauldron.org/prg26/talk/BFJEP7/feedback/ Room S 9 Talk (Short) 2026-10-03T09:00:00+02:00 09:00 00:30 AutoFDO is valued for its low-overhead profile collection that makes it ideal for frequent, large-scale deployment in CI/CD pipelines. However, GCC’s reliance on legacy, out-of-tree tools complicates development and limits both optimizations and profile format evolution. We propose afdo-tools, an in-tree suite designed to consolidate and modernize GCC’s AutoFDO infrastructure, replacing legacy workflows with a unified and lightweight solution. This suite introduces afdo_create, afdo_merge, and afdo_dump, featuring minimal dependencies (relying primarily on libdw and libelf) and streamlining the workflow for both offline perf.data processing and direct, live capture via perf_event_open. This presentation will cover the architectural transition from legacy create_gcov workflows to this integrated approach. We will highlight the performance benefits, demonstrating up to 15x speedup in profile creation, and discuss how native GCC integration simplifies maintenance, bootstrap, and testing. We conclude with validation results on SPEC CPU 2026 and our roadmap for future GCC AutoFDO evolution. prg26-105235-introducing-new-afdo-tools-for-autofdo-in-gcc Kugan Vivekanandarajah en false https://conf.gnu-tools-cauldron.org/prg26/talk/QJ8X9L/ https://conf.gnu-tools-cauldron.org/prg26/talk/QJ8X9L/feedback/ Room S 9 Talk (Short) 2026-10-03T09:30:00+02:00 09:30 00:30 gcc relies on the external autofdo project for hardware profile feedback. perf-gcov is a rewrite of autofdo in the Linux perf framework, which aim to be simpler and has some new functionality. This talk will give an overview of perf-gcov's design and its functionality. prg26-104900-improving-autofdo-with-perf-gcov Andi Kleen en false Slides https://conf.gnu-tools-cauldron.org/prg26/talk/YVMRNE/ https://conf.gnu-tools-cauldron.org/prg26/talk/YVMRNE/feedback/ Room S 9 Birds of a Feather (BoF) 2026-10-03T10:30:00+02:00 10:30 01:00 Configury/Build System BoF The GCC/Binutils/GDB projects share a lot of Autotools and Automake infrastructure. This BoF brings together toolchain developers, maintainers, autotools experts, and anyone with experience in other build systems to discuss: * Current pain points What makes configure slow, hard to debug, or difficult to extend? * Upgrades Should we upgrade Autotools? To which versions? What breaks? What do we gain? * Duplication and necessary cleanups Which patterns are shared across components or trees? What has become redundant due to upgrades? * Shared governance Keeping GCC, Binutils, and GDB in sync. For example, the "config" directory is not identical on both trees. Could we automate synchronization? * Next steps Which improvements are quick wins? What belongs on a long-term roadmap? * Explore longer-term possibilities What would fundamentally improve our build system? prg26-100449-configury-build-system-bof pietro en false https://conf.gnu-tools-cauldron.org/prg26/talk/BM3WHC/ https://conf.gnu-tools-cauldron.org/prg26/talk/BM3WHC/feedback/ Room S 9 Talk (Short) 2026-10-03T11:30:00+02:00 11:30 00:30 Memory and disk are increasingly scarce, so code size is a real cost. Conventional alignment heuristics pad every loop, label, and branch target to fixed boundaries on x86-64, growing the binary in exchange for a possible instruction-fetch improvement. On real-world benchmarks, this blanket alignment increases binary size by an average of about 4%, while the promised gains may not appear. Smart loop alignment rests on a simple observation: a loop small enough to fit within a single cache line should not be allowed to straddle a cache-line boundary (64 bytes on x86-64). Implemented by patching Binutils and GCC, it aligns loops selected by their execution count, from either PGO or static estimates, choosing the loops most likely to benefit from alignment. This avoids the ~4% binary growth of blanket alignment. Reducing binary size without causing any regressions, and easing the memory and disk pressure that comes with it, is the primary aim. Performance was not a target, but the same selectivity also reduces front-end stalled cycles and improves effective I-cache utilization by emitting fewer padding NOPs. prg26-105312-smart-alignment-reducing-code-size-on-x86-without-performance-impact Sarvesh ChandraVenkataramanan KumarBranden Moore en false GCC Patch Binutils Patch Slides https://conf.gnu-tools-cauldron.org/prg26/talk/HS9RPC/ https://conf.gnu-tools-cauldron.org/prg26/talk/HS9RPC/feedback/ Room S 9 Lightning Talks 2026-10-03T12:00:00+02:00 12:00 00:15 The talk is about debugging C/C++ macros like functions. Currently, GDB treats macro expansions as a single opaque step, making it impossible to step into macro bodies, inspect argument values, or set breakpoints inside them. The main idea is to bring function-like debugging capabilities to macros, so that they can be stepped through, inspected, and debugged with the same granularity as regular functions. This improves visibility into macro execution and makes macro-related bugs easier to understand and diagnose. To achieve this, a Clang libTooling-based structure analysis is performed on the source, followed by a preprocessor transformation that is augmented with additional information required for debugging. Compiling this transformed source produces DWARF debug information, from which all the instruction-level mapping needed for macro debugging is derived. Finally, a GDB plugin, built on GDB's Python API, uses this mapping to provide macro-aware stepping, breakpoints, assembly inspection, and argument value inspection. prg26-104865-debugging-of-c-c-macros-like-functions Hayk Aslanyan en Additionally, I will present a demo of the developed [plugin](https://github.com/cast-tech/GDB-Macro-Debugger). false Code Debugging macros like functions https://conf.gnu-tools-cauldron.org/prg26/talk/S8AGLY/ https://conf.gnu-tools-cauldron.org/prg26/talk/S8AGLY/feedback/ Room S 9 Lightning Talks 2026-10-03T12:15:00+02:00 12:15 00:15 AutoFDO on AArch64 keeps maturing: since GCC 16.1, an autoprofiled bootstrap can fall back to Arm SPE sampling on machines without BRBE, and a native profile-generation tool has been posted to the list as an RFC. We want to take this line one step further, because today's flow uses only half of what SPE records: branches are collected, everything else is dropped. Yet the same sampling unit also records, for every sampled load, the facts that matter most — which cache level served it, how many cycles it waited, which address it touched. This is exactly what backend-bound workloads need. On memory-bound services the time goes to memory latency, not bandwidth, and the optimisations that help — data layout, prefetch distance, load speculation — have always leaned on manual experience. With this feedback, the compiler can know which loads miss, and how the data behind them should be placed. We have in fact been exploring this downstream for two years. Since 2024 our distribution's GCC has shipped a memory-side feedback mechanism: cache misses sampled by perf are attributed to source locations through the AutoFDO machinery and stored as an event-typed gcov side file (execution counts, cache misses, and other PMU events each in its own stream), consumed by a dedicated GIMPLE pass. The pass finds memory-intensive loops, analyses each data reference's base variable and data volume, extrapolates across loop nests, then emits prefetch hints for the hottest references targeted at a chosen cache level — including SVE gather prefetch. When the data volume is known at compile time and fits the last-level cache, the prefetch is emitted statically; when it is only known at run time, a runtime check guards it. LLVM has MemProf, built on instrumentation; upstream GCC has neither path, while the hardware has long been ready. What we bring is a design proposal, and we want the community's view: where the data should live (extending the AutoFDO side file, or a new gcov section); where the consumer should attach (a dedicated GIMPLE pass, or folded into the existing prefetch and vectorisation frameworks); and which parts of our downstream design fall short and should be adjusted or redone. prg26-105301-beyond-branches-arm-pmu-spe-as-a-memory-side-profile-source-for-gcc-autofdo huangxiaoquan en This talk is mainly for: people who work on profile/FDO infrastructure, those driving the AutoFDO tooling, and anyone whose workloads are stalled on memory latency rather than branch prediction. In this mechanism, the profile side extends the AutoFDO reader beyond execution counts: cache misses and other PMU events each get their own file, with every count indexed by source location, so an optimisation pass can look up the count for any location. The consumer pass works in six steps. It picks memory-intensive loops using two thresholds, the share and the count of memory instructions; traces each data reference back to its base variable, including indirect and vectorised references; extrapolates data ranges and loop bounds across the nest; filters the loops again by static heuristics or hot paths from the profile; groups references by base variable and ranks them by data volume and access cost; and finally emits prefetch hints for the top groups, naming the target cache level, with both contiguous and SVE gather forms. Where the data volume is computable at compile time and fits the last-level cache, the prefetch is emitted directly; otherwise a runtime check guards it. The memory-intensity thresholds, the target cache level, how many groups to take, and the per-core last-level-cache budget are all tunable parameters. false Beyond Branches: Arm PMU SPE as a Memory-Side Profile Source for GCC AutoFDO.pptx https://conf.gnu-tools-cauldron.org/prg26/talk/BXDCZA/ https://conf.gnu-tools-cauldron.org/prg26/talk/BXDCZA/feedback/ Room S 9 Talk 2026-10-03T13:30:00+02:00 13:30 01:00 Since my [last update on the subject at FOSDEM 2024](https://archive.fosdem.org/2024/schedule/event/fosdem-2024-2796-gdb-on-windows-status-plans), we've had substantial progress on the Windows port plans I presented then (non-stop mode is in, testsuite now works, etc.). However, there is still a lot to be done. In this talk, I'll give a fresh update and talk about work I and others on the ROCgdb debugger team at AMD are doing. This can broadly be put under the "support {x86_64,i686,aarch64}-pc-windows-msvc targets" umbrella. - Teaching GDB about {x86_64,aarch64,i386}-pc-windows-msvc targets - Windows-MSVC vs Windows-GNU GDB ABI split - Windows/MSVC calling conventions - Catching C++ exceptions - Microsoft's C++ name mangling (aka name decoration) scheme (instead of Itanium mangling scheme supported by libiberty) - Vtable & object layout (not Itanium) - Teaching GDB about PDB (Portable Database), Microsoft's debug info format (not DWARF) - Teaching testsuite about {x86_64,aarch64,i386}-pc-windows-msvc targets - Different linker (lld-link or MSFT's link.exe) - Visual C++ headers & libraries, not MinGW - PDB by default - More prg26-105368-gdb-on-windows-status-plans-2026-edition Pedro Alves en false https://conf.gnu-tools-cauldron.org/prg26/talk/Y83C3C/ https://conf.gnu-tools-cauldron.org/prg26/talk/Y83C3C/feedback/ Room S 9 Talk 2026-10-03T14:30:00+02:00 14:30 01:00 Today we have two complementary, disconnected views of a struct: - pahole gives the *static* layout: which fields fall on which cacheline, holes, padding, --reorganize suggestions. It knows nothing about *how* the fields are accessed at runtime. - perf data-type profiling (Namhyung Kim, merged v6.8, full in v6.10, typecln sort key in v6.12) gives the *dynamic* view: for each sampled load/store it resolves the instruction's memory operand through BTF and DWARF location expressions to a (type, member offset) and keeps a per-byte-offset histogram of access counts/periods. This talk will present recent work on making perf emit a JSON document describing the data-type access profile aggregated in histograms -- carrying each type's DSO and build ID so the consumer can locate the right DWARF and verify the same binary -- as well as CTF data with per sample info on data address, timestamp, etc, and make pahole consume it to pretty-print structs with hot/co-accessed fields highlighted per cacheline, propose cacheline groups (emitting the exact C macros the networking code uses), and flag false-sharing candidates. prg26-105373-data-type-profiling-pairing-perf-with-pahole Arnaldo Carvalho de Melo en false https://conf.gnu-tools-cauldron.org/prg26/talk/PWJ87E/ https://conf.gnu-tools-cauldron.org/prg26/talk/PWJ87E/feedback/ Room S 9 Birds of a Feather (BoF) 2026-10-03T16:00:00+02:00 16:00 01:00 An opportunity for the GDB community to meet to discuss all things related to the GNU Debugger project. prg26-105366-the-gdb-bof Pedro Alves en false https://conf.gnu-tools-cauldron.org/prg26/talk/RDQK7U/ https://conf.gnu-tools-cauldron.org/prg26/talk/RDQK7U/feedback/ Room S 5 Talk 2026-10-03T09:00:00+02:00 09:00 00:45 Shrink-wrapping is a GCC back-end optimization that avoids placing the function prologue unconditionally at the start of every function. Instead, it delays prologue emission to only those paths that need it: it finds the tightest dominator block that covers all instructions requiring the stack frame to be set up and places the prologue on the edge entering that block. When a function has an early-exit path that does not call anything and does not use callee-saved registers, shrink-wrapping can eliminate prologue/epilogue overhead on that path entirely. However, this optimization can fail, not because the function structure is unsuitable, but because earlier register-allocation decisions can force the prologue to be emitted in the entry block. More specifically, any instruction placed in the entry block that references any of the stack pointer or frame pointer registers, or that modifies a callee-save register, will force the prologue into the entry block, defeating shrink-wrapping entirely. This talk examines three distinct ways in which IRA and LRA allocation decisions prevent shrink-wrapping from happening, and the fixes that were developed to address them: - A missing cost term in IRA's post-coloring refinement pass (_improve_allocation_) — the save/restore cost of choosing a callee-saved register was absent entirely, allowing the pass to override a perfectly good caller-saved register assignment with a callee-saved one. - A frequency-scaling omission in IRA's primary assignment function (_assign_hard_reg_) — the callee-save save/restore cost was present but not scaled by the entry-block execution frequency, making it negligibly small compared to frequency-weighted register usage costs, again biasing the allocator toward callee-saved registers. - Fixing this issue resulted in performance improvements in SPEC 2017 (**4%** in perlbench and **2.6%** in povray) on Power10 processor. - Eager spill placement in LRA's inheritance/splitting pass (_inherit_in_ebb_) — When a pseudo assigned to a caller-saved hard register has a live range that crosses a call, LRA inserts a spill immediately after the pseudo's definition. If that definition is in the entry block but the call is in a later block of the same EBB, the spill — which references the stack pointer — lands in the entry block. This prevents shrink wrapping. The talk will discuss the root causes, the fixes and the interaction between register allocation and shrink wrap optimization. prg26-105405-register-allocator-and-shrink-wrapping Surya Kumari J en false https://conf.gnu-tools-cauldron.org/prg26/talk/3HRHA9/ https://conf.gnu-tools-cauldron.org/prg26/talk/3HRHA9/feedback/ Room S 5 Lightning Talks 2026-10-03T09:45:00+02:00 09:45 00:15 Tuning a new AArch64 core in a released GCC requires connecting hardware measurements to the compiler decisions that shape application performance. We maintain AArch64 support across several GCC release lines and present a GCC 14 case study on an SVE server platform, exploring how measured evidence can refine a conservative tuning policy into more selective decisions. The talk follows tuning choices through five levels of evidence: instruction calibration, focused kernels, compiler inspection, application profiling and deployment validation. Instruction experiments establish dependency latency and throughput under stated conditions. Kernels vary trip count, data layout and working-set size, while vectorizer and RTL inspection identify the decisions that change. Hot-function analysis and PMU events then help investigate their effects in applications. Finally, full-suite single-copy and 96-copy measurements show how gains depend on the deployment regime. Two examples anchor the discussion. A vector-store cost adjustment changes short-loop behavior, trading gains in one workload against losses in another. A second candidate reduces instruction count while increasing cycles, raising questions about memory behavior that require further isolation. Scheduling experiments illustrate trade-offs involving register pressure and allocation. We also trace the consumers of three kinds of tuning controls—target policy, vector-cost heuristics and vector-width estimates—to explain their distinct roles in code generation. Results are internal research measurements with explicit baselines and repeat counts, including only one repetition of the 96-copy runs. These findings motivate incremental proposals for the GCC community: document tuning fields with units and consumer semantics, expose the effective policy and model used for a function, and attach regression kernels and measurement provenance to tuning changes. Building on the AArch64 JSON tuning interface, we discuss release-specific compatibility checks and adapters for carrying tuning into compilers whose code-generation capabilities already cover the workload. Scheduling descriptions and target-side plugin extensions need separate capability, API and lifetime contracts. Loading tuning data cannot supply instruction patterns or ISA support that the compiler does not implement. prg26-105300-helping-released-gccs-support-new-cpus-from-field-problems-to-a-cross-version-interface-proposal huangxiaoquan en false Helping Released GCCs Support New CPUs slides https://conf.gnu-tools-cauldron.org/prg26/talk/ARPWWW/ https://conf.gnu-tools-cauldron.org/prg26/talk/ARPWWW/feedback/ Room S 5 Talk (Short) 2026-10-03T10:30:00+02:00 10:30 00:30 Fortran has no equivalent of C and C++ intrinsic headers for explicit SIMD programming. We investigated where manual vectorization could usefully complement gfortran's auto vectorizer, using scientific applications to identify patterns that remain difficult to optimize automatically. This talk presents work towards explicit SIMD support in GNU Fortran, covering alignment control, vector types, and an intrinsic interface to architecture specific vector operations. We will discuss the motivation for these extensions, what we learned from applying them to real vectorization problems, and the remaining design questions around exposing low-level SIMD facilities in a way that fits naturally into Fortran. prg26-104810-manual-vectorization-for-gnu-fortran Magnus WeinmüllerHenri Menke en false https://conf.gnu-tools-cauldron.org/prg26/talk/L9WJP7/ https://conf.gnu-tools-cauldron.org/prg26/talk/L9WJP7/feedback/ Room S 5 Talk 2026-10-03T11:00:00+02:00 11:00 01:00 An update of the current status of OpenMP, OpenACC and offloading in GCC, including what has been achieved last year. A few highlights and, additionally, an outlook for next years is given of the tasks that are planned or that should be done in the near term. prg26-103791-offloading-openmp-and-openacc-in-gcc Tobias BurnusThomas Schwinge en false Slides for Offloading, OpenMP, and OpenACC in GCC https://conf.gnu-tools-cauldron.org/prg26/talk/C3PSEQ/ https://conf.gnu-tools-cauldron.org/prg26/talk/C3PSEQ/feedback/ Room S 5 Talk (Short) 2026-10-03T12:00:00+02:00 12:00 00:30 The OpenMP Tools Interface (OMPT) provides a standardized mechanism for performance analysis and tooling, enabling developers to gain detailed insight into OpenMP program execution. While the LLVM OpenMP runtime provides a mature OMPT implementation, libgomp has no support at the moment, limiting the availability of performance tools on GCC compiled code. This talk presents our work to add OMPT support in libgomp. We describe the implementation of the core OMPT infrastructure, including the general callback interface, the general OMPT API entry points, and support for device callbacks. The implemented functionality substantially improves compatibility with existing OMPT-based tools and brings libgomp much closer to a complete implementation of the specification. Beyond the implementation itself, we will discuss the performance implications of enabling OMPT based on the EPCC benchmark suite. Additionally, we will speak about architectural changes proposed for upstream libgomp. In particular, we will motivate the partial conversion of the runtime to C++ to leverage templating code with and without OMPT enabled, and we introduce additional internal runtime API entry points required to expose events that are not currently observable through libgomp's existing interfaces. prg26-104150-libgompt-enabling-ompt-for-libgomp Jan KrausThomas Schwinge en Join us for a talk on ongoing work to add OpenMP Tools Interface (OMPT) support to libgomp. OMPT is key for performance analysis and tooling, but until now GCC-compiled OpenMP programs have had limited access to the OMPT-based tooling ecosystem. We will present the new core OMPT infrastructure in libgomp, including callback handling, API entry points, and device callback support. We will also discuss performance results using the EPCC benchmark suite and outline proposed architectural changes for upstream libgomp. This talk should be interesting for anyone working on OpenMP runtimes, GCC/libgomp, performance tools, or the future of tooling support in the GNU ecosystem. false Presentation Slides https://conf.gnu-tools-cauldron.org/prg26/talk/CDZHQJ/ https://conf.gnu-tools-cauldron.org/prg26/talk/CDZHQJ/feedback/ Room S 5 Talk (Short) 2026-10-03T13:30:00+02:00 13:30 00:30 x86_64 Shadow Stack support has been available across the GNU toolchain components for some time now, but no distribution has broadly enabled the runtime by default. Fedora has now begun working on shadow stack enablement on x86_64 with plans to ship in Fedora 46 (~April 2027). This talk summarizes the ongoing efforts to enable Shadow Stack mode in Fedora, including the experiences and problems encountered so far. We will discuss Python and Rust ecosystems, handwritten assembly, various ways in which build artifacts are rendered incompatible, as well as "permissive" mode and multi-threading. prg26-105777-enabling-glibc-shadow-stack-runtime-in-fedora Arjun Shankar en false https://conf.gnu-tools-cauldron.org/prg26/talk/TXRXTF/ https://conf.gnu-tools-cauldron.org/prg26/talk/TXRXTF/feedback/ Room S 5 Birds of a Feather (BoF) 2026-10-03T14:00:00+02:00 14:00 01:00 A follow-up to the 2025 GCC and AI BoF. Last year we opened the discussion on where GCC intersects with AI/ML, this year we take stock of what's moved, what hasn't, and where the community should focus next. As with last year, this is a community discussion session rather than a talk - I'll moderate and keep the conversation moving, but the content comes from attendees. Bring your experiences, questions, and disagreements. prg26-104687-bof-on-gcc-and-ai Pietra Ferreira en The goal is to bring together people actively working at this intersection (or interested in it) to compare notes on what's worked, and leave with a clearer sense of concrete next steps. Some possible discussion topics: - What's changed since last year: new accelerator targets, upstream activity etc. - Experiences building GCC/toolchain support for custom NPU and vector extensions: what's reusable versus target-specific. - Where is external tooling (runtime-level) a better fit? false https://conf.gnu-tools-cauldron.org/prg26/talk/9S88YF/ https://conf.gnu-tools-cauldron.org/prg26/talk/9S88YF/feedback/ Room S 5 Birds of a Feather (BoF) 2026-10-03T15:00:00+02:00 15:00 00:30 A BoF covering the BPF target support in the GNU toolchain. Issues and discussions related to the BPF backend, BTF debug info, assembler, etc. as well as the Linux kernel BPF verifier and ecosystem are on topic for this session. prg26-102297-bpf-bof David FaustVineet GuptaJose Marchesi en false https://conf.gnu-tools-cauldron.org/prg26/talk/YF3MFA/ https://conf.gnu-tools-cauldron.org/prg26/talk/YF3MFA/feedback/ Room S 5 Talk 2026-10-03T16:00:00+02:00 16:00 01:00 This talk will cover: - a prototype implementation of an [LSP server]([url](https://langserver.org/)) using GCC's frontends - improvements to GCC's `-fanalyzer` option - improvements to GCC's diagnostics subsystem prg26-96480-what-s-new-with-diagnostics-in-gcc-17 David Malcolm en false Slides for “What's new with diagnostics in GCC 17” https://conf.gnu-tools-cauldron.org/prg26/talk/7R9YLV/ https://conf.gnu-tools-cauldron.org/prg26/talk/7R9YLV/feedback/ Room S (Floor 3) Birds of a Feather (BoF) 2026-10-03T09:00:00+02:00 09:00 01:00 The GNU C Library is used as the C library in the GNU systems and many other systems with the Linux kernel. The library is primarily designed to be a portable and high performance C library. It aims to follows all relevant standards including ISO C17 and POSIX.1-2008. It is also internationalized and has one of the most complete internationalization interfaces known. prg26-95813-gnu-c-library-bof Carlos O'DonellAdhemerval Zanella Netto en This BoF aims to bring together developers of other components that have dependencies on glibc and glibc developers to talk about the following topics: * Planning for Core Toolchain Infrastructure transition and open questions. * Planning for glibc 2.45 and what work needs to be done between September 2026 and February 2027. * Planning for glibc 2.46 and what work needs to be done between February 2027 and August 2027. ... and more. false https://conf.gnu-tools-cauldron.org/prg26/talk/TZERQV/ https://conf.gnu-tools-cauldron.org/prg26/talk/TZERQV/feedback/ Room S (Floor 3) Birds of a Feather (BoF) 2026-10-03T10:30:00+02:00 10:30 01:00 In this session, we are mainly going to introduce new added x86 features in recent years, like APX and ACE. Based on that, we are going to share and discuss what we are going to do in GCC17, including ACE enabling, codesize investigation, etc. prg26-104209-x86-bof Haochen JiangVenkataramanan KumarHongtao Liu en Discussions are warmly welcomed in the BoF. Here is what we will prepare in advance for background: For APX part, we will have a "brief" introduction for all the features. For ACE part, we will mainly focus on the current implementation in GCC17, and our implementation difference with LLVM. For codesize investigation, we have noticed that, comparing to GCC13, GCC16 has a big increasement on codesize though we also gained a lot for performance. We will share what we are doing and going to do to control the inflation of codesize. false Slides for BoF https://conf.gnu-tools-cauldron.org/prg26/talk/L7UHWJ/ https://conf.gnu-tools-cauldron.org/prg26/talk/L7UHWJ/feedback/ Room S (Floor 3) Talk (Short) 2026-10-03T11:30:00+02:00 11:30 00:30 The CTFv4 extension of the CTF file format into a superset of BTF is nearly complete. Once it's working, what can we do with systemwide type information for all C programs? One possibility we explore in this talk is to use some simple linker extensions to provide real-time, linear-time ABI checking in ld.so to determine for every running program whether any of the C libraries it uses has changed incompatibly since the program was linked in a way that breaks the program, without linking ld.so with libctf or requiring it to do anything more difficult than a few equality comparisons and strcmps. The end goal is to be able to see something like this: $ emacs warning: libxml.so.2.13.9: incompatible symbol: linked against xmlDocPtr xmlReadMemory (const char *, int, const char *, const char *, int) but running against xmlDocPtr xmlReadMemory (const char *, int, const char *, const char *) (a contrived example: xmlReadMemory has not actually broken ABI. ld.so invokes a helper program that uses libctf to print that output, but does not itself need to use libctf.) This is only partly written so far (I hope to get the non-glibc portions complete before the talk, which is nearly everything): we explore the design of this scheme in part so that the audience can spot any serious errors before it causes widespread breakage, and to see if people can suggest improvements to the general design. prg26-104149-towards-real-time-abi-compatibility-assurance-with-libctf Nick Alcock en Design overview of a scheme to use type information in C programs and shared libraries to provide (fast, linear-in-number-of-symbols) nearly-precise reporting on broken ABIs, both in libabigail and in ld.so itself (yes, it's that fast). I'll be focusing on interaction with glibc and libabigail mostly so that people can tell me if the whole idea breaks as soon as it hits programs in the real world (and if it's even desirable to do this at all). false https://conf.gnu-tools-cauldron.org/prg26/talk/ALWGLG/ https://conf.gnu-tools-cauldron.org/prg26/talk/ALWGLG/feedback/ Room S (Floor 3) Talk (Short) 2026-10-03T12:00:00+02:00 12:00 00:30 On Linux, the dynamic linker applies every relative relocation eagerly at startup. In large position-independent binaries, relative relocations can account for 99% of all relocations and 80-93% of `ld.so`'s runtime, and each one writes to a page, triggering a copy-on-write fault that dirties memory whether or not the process ever touches that page. Windows and macOS avoid this with in-kernel "page-in" linking, but only by fixing library load addresses or changing the executable format. Linux has had no equivalent, because deferring relocations means intercepting page faults, and the existing mechanism – `userfaultfd` – is too slow and requires a handler thread the dynamic linker cannot safely spawn. This talk introduces `bpf_fault`, a framework for running custom page-fault handlers directly in the kernel as eBPF programs, and shows how we experimented with it to build lazy dynamic linking for Linux. I'll cover how the glibc dynamic linker registers each object's writable segments with an eBPF handler and how the handler applies only the faulting page's relocations at fault time. The result is deferred-relocation semantics with no changes to the ELF format or the process loader, leading to 52.7% faster startup on microbenchmarks. On widely-used applications like Chrome and clang, we see 18-40% faster startup time and up to a 50% reduction in dirty memory. prg26-103143-lazy-dynamic-linking-for-linux-deferring-relative-relocations-with-ebpf Tal Zussman en false Paper Repo Slides https://conf.gnu-tools-cauldron.org/prg26/talk/3PPGKX/ https://conf.gnu-tools-cauldron.org/prg26/talk/3PPGKX/feedback/ Room S (Floor 3) Birds of a Feather (BoF) 2026-10-03T13:30:00+02:00 13:30 01:00 Session for all things Arm & AArch64. Arm will present its roadmap but we welcome any topics or your own (quick) roadmap presentations on these ports. prg26-104801-arm-aarch64-bof Andre VieiraTamar Christina en false https://conf.gnu-tools-cauldron.org/prg26/talk/9PMLD9/ https://conf.gnu-tools-cauldron.org/prg26/talk/9PMLD9/feedback/ Room S (Floor 3) Birds of a Feather (BoF) 2026-10-03T14:30:00+02:00 14:30 01:00 Annual BOF on vectorization and related topics with focus on architectural decisions going forward. prg26-98225-vectorizer-bof Richard BienerTamar ChristinaRobin Dapp en false https://conf.gnu-tools-cauldron.org/prg26/talk/AVZDSN/ https://conf.gnu-tools-cauldron.org/prg26/talk/AVZDSN/feedback/ Room S (Floor 3) Birds of a Feather (BoF) 2026-10-03T16:00:00+02:00 16:00 01:00 Discussion of RISC-V issues. High level agenda items TBD, but would likely include this areas: * State of the various tools (gcc, glibc, gdb, valgrind, etc) on RISC-V * Overview of optimzation efforts over the last few years + future work * Major challenges for the RISC-V community prg26-101594-risc-v-bof Jeff LawRobin Dapp en false https://conf.gnu-tools-cauldron.org/prg26/talk/9QEWWH/ https://conf.gnu-tools-cauldron.org/prg26/talk/9QEWWH/feedback/ Room S 9 Birds of a Feather (BoF) 2026-10-04T09:00:00+02:00 09:00 01:00 The Algol 68 front-end got merged in GCC 16 and is under active development. In this BoF the ga68 developers will meet and discuss about the current status of the front-end, known issues, achieving ABI stability in GCC 17, the design of several features and GNU extensions to the language, preludes/libraries, the Algol 68 support in the GNU build system, the Algol 68 support in GDB, etc. Everyone is welcome to join this BoF, especially new people wanting to contribute to the toolchain in general and GCC front-ends in particular. prg26-105274-gnu-algol-68-bof /media/prg26/submissions/DLBVLV/image_uusP61R.webp Jose MarchesipietroMohammad-Reza Nabipoor en false https://conf.gnu-tools-cauldron.org/prg26/talk/DLBVLV/ https://conf.gnu-tools-cauldron.org/prg26/talk/DLBVLV/feedback/ Room S 9 Talk 2026-10-04T10:30:00+02:00 10:30 01:00 Kernel Control Flow Integrity (KCFI) hardens the Linux kernel against function pointer hijacking by validating each indirect call against its expected function-type signature. This protection has, until recently, only existed in Clang. This talk is the story of bringing it to GCC: why KCFI is needed, how the ABI works, giving myself a crash course in GCC's internals, experimenting with implementation choices across front, middle, and backend code, adding coverage and regression tests as I hit bugs, and working through reviewer feedback across more than a dozen revisions. prg26-105070-kcfi-comes-to-gcc-code-reuse-defenses-for-the-linux-kernel Kees Cook en false https://conf.gnu-tools-cauldron.org/prg26/talk/FXG777/ https://conf.gnu-tools-cauldron.org/prg26/talk/FXG777/feedback/ Room S 9 Talk 2026-10-04T11:30:00+02:00 11:30 01:00 During Libabigail 3.0 development, the internal representation of the Application Binary Interface is constructed using a set of multi-threaded algorithms. This new model aims at leveraging the increasing number of CPU cores available on current machines to reduce the processing time required to analyze and compare ABIs of binaries accompanied with sizable debug information in the DWARF format. This talk presents this new ABI analysis model and compares it to the previous strategies. It presents the current performance improvements and covers the faced challenges as well as the improvement opportunities still ahead. prg26-105444-speeding-up-abi-analysis-of-big-elf-dwarf-binaries-with-multi-threading Dodji Seketeli en false PDF slides https://conf.gnu-tools-cauldron.org/prg26/talk/98FKUB/ https://conf.gnu-tools-cauldron.org/prg26/talk/98FKUB/feedback/ Room S 9 Talk (Short) 2026-10-04T13:30:00+02:00 13:30 00:30 "GUTA" (pronounce with a hard "G" and a soft "T") is "GCC's Unified Threading Abstraction", a new and work-in-progress implementation of SIMT-style/CUDA-like programming abstractions in GCC, currently for NVIDIA GPU code offloading only (GCC/nvptx back end), but later extensible for AMD GPU code offloading (GCC/GCN back end), and potentially others. We'll quickly present how CUDA-like GPU code offloading differs from OpenACC and OpenMP 'target' (conceptually, and implementation-wise), the current state of the implementation (small set of CUDA features currently implemented in GUTA), CUDA ('nvcc') vs. GUTA results for BabelStream, miniBUDE benchmarks, an outlook of what else this might be useful for -- and finally the question: do we want this in GCC upstream? prg26-105416-gpu-programming-with-guta-gcc-s-unified-threading-abstraction Thomas Schwinge en false 'GNU Tools Cauldron 2026 - GPU programming with GUTA_ GCC's Unified Threading Abstraction.pdf' https://conf.gnu-tools-cauldron.org/prg26/talk/9ULSQA/ https://conf.gnu-tools-cauldron.org/prg26/talk/9ULSQA/feedback/ Room S 9 Birds of a Feather (BoF) 2026-10-04T14:00:00+02:00 14:00 01:00 The Linux kernel, which is by far one of the biggest, more complex and more important free software programs around, is (still) mainly built using the GNU Toolchain. There is an intimate relationship between toolchain and kernel. Compiling a huge, complex and specialized program such as the kernel often implies facing challenging or unusual requirements on the toolchain side. This includes security related requirements. Also, some of the toolchain components interface directly with the kernel. In the case of glibc, it even provides the main visible interface from the kernel to userland programs. The support for BPF is also mainly Linux kernel specific. This relationship benefits both projects. For example, an actively maintained toolchain can quickly include kernel specific enhancements. And vice versa, the toolchain benefits from the associated relevance that makes corporations support its development. It is certainly not unusual for a feature introduced primarily for kernel usage to also be very useful to other programs. Examples of this are the support for patchable function entries, "asm goto", fentry , and several security related features. In order to improve this relationship a Toolchains Track has been organized for some years now at the Linux PLumbers Conference. The aim of the track is to fix particular toolchain (both GNU and LLVM) issues which are of interest to the kernel and, ideally, find and agree on solutions right away, during the track, making the best use of the opportunity to discuss the issues live with kernel developers and maintainers. The LPC toolchains track is proving very useful, although it is not always easy to bring toolchain hackers there, given it is a kernel specific conference. We propose to have a Toolchain and Linux Kernel BoF during Cauldron this year, as we did last year, with the participation of several Linux kernel maintainers. The goals of the BoF are (a) to discuss about particular requirements, desired features and on-going developments that are relevant to the kernel and (b) to gather kernel related questions/input/feedback from the toolchain developers so we can bring the issues to the LPC Toolchains Track, which will be held immediately after Cauldron, also in Prague. prg26-105272-toolchain-and-linux-kernel-bof Jose MarchesiMiguel OjedaAlexeiAlejandro ColomarPaul McKenneyNick Desaulniers en false https://conf.gnu-tools-cauldron.org/prg26/talk/TRZN7Z/ https://conf.gnu-tools-cauldron.org/prg26/talk/TRZN7Z/feedback/ Room S 5 Talk 2026-10-04T09:00:00+02:00 09:00 01:00 Points-to analysis (PTA) is a very important analysis for GCC's optimizer. GCC has an IPA variant of PTA, but its usefulness is currently very limited. I believe there is untapped potential in IPA PTA and my long-term goal is to harness it. I'd like to transform IPA PTA into a useful and practical analysis pass. However, GCC's IPA PTA is based on Andersen's algorithm, which doesn't scale well. To overcome this challenge, I implemented Steensgaard's algorithm, which scales almost linearly. At the time of writing this abstract, I'm preparing to submit my work upstream. I'll introduce the project and talk about all the interesting problems I've encountered, possible solutions, and other future plans. prg26-104155-practical-ipa-points-to-with-steensgaard-s-algorithm-why-how-and-what-s-the-status Filip Kastl en false Presentation slides https://conf.gnu-tools-cauldron.org/prg26/talk/8CDLKZ/ https://conf.gnu-tools-cauldron.org/prg26/talk/8CDLKZ/feedback/ Room S 5 Talk 2026-10-04T10:30:00+02:00 10:30 01:00 MESA is a branch of gcc that extends it in a brand new way. It supports a complete dump of the GENERIC tree, and reassembly from the dump to the middle-end, just as if the input came from a front-end. MESA exists to provide GCC developers with a concrete syntax for GENERIC. It is a boon to front-end developers, who could compare similar constructs in different languages. It gives all developers working with GENERIC -- as output or input -- an unambiguous verifiable manifestation of the structure. To the author's knowledge, MESA is novel compiler technology. prg26-104461-mesa-the-middle-end-semantic-assembler James K. Lowden en We call MESA a "semantic assembler" because it's an assembler for GENERIC semantics. Each MESA function (with couple exceptions) corresponds 1:1 to a GENERIC function or macro. MESA thereby presents the developer with tractable malleable syntax for precise manipulation of the GENERIC tree. When the front-end completes its work and submits it to the middle-end for compilation, MESA produces a dump of the entire GENERIC tree. The syntax used is Scheme. Each GENERIC node is represented as a Scheme variable or function. Functions are Scheme bindings of GENERIC operations -- functions and macros -- exported to Guile. The MESA dump is "sweetened" by Scheme macros to make those operations less tedious to read. To facilitate human comprehension, node names are taken from constituents in the input language. To prove the dump is correct, the user may use MESA to send it to the compiler. We invoke GNU Guile to read the dump and interpret it as Scheme. MESA itself does no interpretation: the input is Scheme, interpreted by Guile. As the interpreter invokes MESA functions, the middle-end is alerted in just the same way, and same sequence, as if invoked from C. The middle-end never sees an S-expression, and the Guile compiler is unconcerned that some Scheme functions happen to be implemented in C. MESA represents a new way to use and think about compiler technology. Historically of course compilers did not have a middle-end. Of modern compilers, none describes anything similar to MESA. The LLVM IR, for example, represents an idealized assembler. The intermediate representations of Rust and Swift are not interchangeable; each reflects constructs of the original language. MESA by contrast is a Scheme abstraction of the GCC middle-end "machine". Although it originated in the COBOL front end, there is no COBOL in it. It is, one might say, as GENERIC as they come. false https://conf.gnu-tools-cauldron.org/prg26/talk/7LR8AS/ https://conf.gnu-tools-cauldron.org/prg26/talk/7LR8AS/feedback/ Room S 5 Birds of a Feather (BoF) 2026-10-04T11:30:00+02:00 11:30 01:00 The GNU toolchain packages are not only the showcase for the most excellent toolchain software ever written. They are also the showcase of the inventive licensing structure known as copyleft. The toolchain community is often at the forefront of licensing questions and concerns. This BoF session will be an open discussion about many of the questions/concerns that were raised at and since last year's Cauldron (and elsewhere in community discussions). Discussion will include any additional topic that toolchain maintainers and hackers may be interested in discussing. Some examples of items raised since last year's Cauldron that will be discussed include: * Scenarios and topics concerning copyright assignment and code-sharing in different GNU packages and lessons we can all learn from here. * Discussion of current GNU & FSF policies on acceptance of (whole or in part) LLM-gen-AI generated code in the toolchain packages and what are current package-specific challenges, discussion of work SFC has done with its projects on LLM-gen-AI policies, and the complementary work that FSF and SFC are doing to navigate this difficult era of LLM-gen-AI contributions. * What are the best ways to welcome new contributors to the GNU toolchain given their varying usage of LLM-gen-AI tools? * Any questions about the GCC RTL Exception that the audience has. prg26-105225-toolchain-licensing-bof Denver GingerichIan Kelling en false https://conf.gnu-tools-cauldron.org/prg26/talk/QAQXDB/ https://conf.gnu-tools-cauldron.org/prg26/talk/QAQXDB/feedback/ Room S 5 Talk 2026-10-04T13:30:00+02:00 13:30 01:00 Sourceware has provided the infrastructure for the GNU Toolchain projects and core developer tools for more than 25 years. The last four years, Sourceware has been a Software Freedom Conservancy member project with its of own resources and budget. Last year, we completed our infrastructure hardware refresh cycle, increased redundancy, isolation, and doubled our hardware and network capacity. More than half of the hardware is used for various CI systems across 8 different architecture. Which do ~15,000 builds a months. Lets dive into what is currently being build and whether that is actually useful. Learn how to add your own builders, use try-bots, integrate with patchwork CI/CD and how to use the dedicated forgejo runners. For this fiscal year, we would like to shift our budget focus to spend less on "iron" and more on "services and people". We would like to (a) finally provide financial support/compensation to our partner OSUOSL, (b) hire paid staff/consultants to help with services upgrades and VM migrations, and (c) look into funding upstream Forgejo improvements. We'll end with a discussion with Sourceware PLC, FSF (GNU Toolchain projects fiscal sponsor) and SFC (Sourceware fiscal sponsor) staff members to answer any questions on how we are running the community infrastructure together with our other partners. prg26-105323-sourceware-infrastructure-organization-and-automation /media/prg26/submissions/SVVBRS/image_ceQkiXK.webp Mark J. WielaardDenver GingerichIan Kelling en - 20 minutes Overview of available Sourceware resources, automating your CI processes (buildbots, try-bots, pre/post-commit-CI/CD, snapshots, forgejo runners, patchwork's curator, etc.) - 20 minutes introduction to the Sourceware organization and goals for next year - 20 minutes Q&A with Sourceware PLC, FSF and SFC staff https://builder.sourceware.org https://sourceware.org/financials.html https://sourceware.org/sourceware-wiki/servers-and-services-2026/ false Talk slides https://conf.gnu-tools-cauldron.org/prg26/talk/SVVBRS/ https://conf.gnu-tools-cauldron.org/prg26/talk/SVVBRS/feedback/ Room S (Floor 3) Talk 2026-10-04T09:00:00+02:00 09:00 01:00 LLMs have become common and their ability is regularly improving. WIthin the guidelines provided by the AI working group for the GCC project, how can we use LLMs to improve patch generation, patch review and code analysis? We will work through examples of using an LLM to identify problems in a patch during the development phase to help understand the strengths and weaknesses of an LLM in this context. Similarly we will look at how a patch reviewer might use an LLM and derive some best practices for using LLMs to generate higher quality patches. The second half of the discussion will show real world examples of using an LLM to identify code sequences that can likely be improved. We will discuss several good optimizations found by LLMs as well as various pitfalls to larger scale LLM analysis. prg26-101593-using-llms-in-patch-generation-patch-review-and-code-analysis Jeff Law en false https://conf.gnu-tools-cauldron.org/prg26/talk/TPLVAA/ https://conf.gnu-tools-cauldron.org/prg26/talk/TPLVAA/feedback/ Room S (Floor 3) Birds of a Feather (BoF) 2026-10-04T10:30:00+02:00 10:30 01:00 In the past year, GCC Steering Committee announced the creation of Working Groups for supporting the work of the SC. These are designed to enable the community to come together for specific topics and create proposals for the SC to reviews in order to take policy discussions forward. This panel discussion will explain the idea behind it, show how the first WG (AI policy WG) operated and how future WGs can be formed along with answering any questions from the community. prg26-104672-working-groups-in-gcc SudiJason MerrillCarlos O'DonellDavid Edelsohn en false https://conf.gnu-tools-cauldron.org/prg26/talk/XTNMU3/ https://conf.gnu-tools-cauldron.org/prg26/talk/XTNMU3/feedback/ Room S (Floor 3) Talk 2026-10-04T11:30:00+02:00 11:30 01:00 SIMT (Single Instruction Multiple Threads) is another way to model SIMD, a.k.a. vectorization. It's possibly better suited to GPUs for OpenMP/OpenACC use-cases, where the parallelism is already marked up, so I've spent the last 8 months implementing _experimental_ support to GCC, specifically for the AMD GCN port. The talk will discuss what's wrong with the existing SIMD support, what design decisions were made, why it's back-end specific, what code transformations are necessary, and how this compares to the NVPTX port that already implements SIMT. prg26-104827-converting-amd-gcn-to-simt-vectorization Andrew Stubbs en false Presentation slides https://conf.gnu-tools-cauldron.org/prg26/talk/KKJKZK/ https://conf.gnu-tools-cauldron.org/prg26/talk/KKJKZK/feedback/ Room S (Floor 3) Talk (Short) 2026-10-04T13:30:00+02:00 13:30 00:30 elfutils has shipped an experimental --enable-thread-safety configure option since 2009. Coverage has been incomplete, the concurrency contract was never precisely specified, and lock overhead limited multithreaded scalability. Over the past few years we have been addressing these issues and working towards official thread safety support for libelf and libdw. In this talk I will give an overview of the design, development history, challenges and recent progress of this work, as well as what remains until we can declare thread safety officially supported. This talk may be of interest to developers whose tools consume libelf or libdw, as well as anyone interested in retrofitting thread safety onto mature C libraries. prg26-105318-elfutils-the-road-to-thread-safety Aaron Merey en false https://conf.gnu-tools-cauldron.org/prg26/talk/3HWNAL/ https://conf.gnu-tools-cauldron.org/prg26/talk/3HWNAL/feedback/