GNU Tools Cauldron 2026

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.

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 frees, 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.

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/

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.

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.

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.

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

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.

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.

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.

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

An opportunity for a GNU Toolchain community conversation with the members of the Steering Committees of the GNU Toolchain projects (GCC, GLIBC, Binutils, GDB).

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.

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.

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.

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.

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.

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?

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.

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.

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.

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.

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.

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.

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.

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.

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.

Since my last update on the subject at FOSDEM 2024, 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

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.

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.

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.

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.

Annual BOF on vectorization and related topics with focus on architectural decisions going forward.

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.

An opportunity for the GDB community to meet to discuss all things related to the GNU Debugger project.

This talk will cover:

• a prototype implementation of an LSP server using GCC's frontends
• improvements to GCC's -fanalyzer option
• improvements to GCC's diagnostics subsystem

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.