GNU Tools Cauldron 2022

<< GNU Tools Cauldron 2021 | GNU Tools Cauldron 2023 >>

GNU Tools Cauldron is back in person!

2022 Cauldron is back in the beautiful city of Prague after 2 years of virtual events, but with a hybrid twist. This year we are aware some people may not be able to attend in person so there is the availability to present and engage with the community remotely (although we would really like to see you there!). It will be hosted the weekend following the Linux Plumbers Conference in Dublin where GNU Tools Cauldron topics will be involved in the Toolchains and Kernel track (previously the Toolchains and Kernel microconference).

We hope to see you there!

Please email if you would like to attend either in-person or virtually, indicating your T-shirt size and any dietary requirements if you attending in-person. We'll contact you later in the year with details of how to pay.


Organizing committee:

Boat trip

We leave today, September 17 at 6:30 pm from Dvořákovo nábřeží, pear no. 2 of Prague Boats. map, Agnes de Bohemia boat. Coordinates are: 50.09197914263514, 14.416358338629554. You can walk with us from the conference venue. We will leave at 6pm. Don't be late!


We shall provide advice on COVID-19 protection measures shortly before the event. This will draw on the latest local advice at the time. You can see the current advice from Charles University here, but this is expected to be updated before our meeting in September.


We are still looking for more sponsors of this years Cauldron. Sponsors provide support for community volunteers, bursaries to enable students to attend and subsidise the cost for all participants.


This year after discussions with the community at previous Cauldrons and our major backers, we are introducing a charge to attend Cauldron 2022 in person. Thanks to generous support from our sponsors, the price this year will be £50. There are a number of limited free passes which are available on request.

If you are attending Cauldron 2022 virtually, the conference is free to attend.

We are still organising the logistics and putting together the cost of this years event. Please keep an eye on this page for updates including the link to register to attend the event.

(And if you are wondering why the tickets for a Czech meeting are in pounds sterling, it is because the GNU Tools Cauldron has been set up as a UK Community Interest Company).

Video recordings and slides

Talks and Slides will be recorded as part of the event, so if you are unable to attend a talk they will be able to be viewed after the event.

Live broadcast

If everything will go well, we will broadcast live at GNU Tools Cauldron 2022 youtube channel.


S9, 118 seats, 1st floor

S5, 118 seats, 2nd floor

S10, 24 seats, 1st floor


9:00 - 09:50

Registration, tea & coffee

9:50 - 10:00


10:00 - 11:00

GCC -fanalyzer update

11:00 - 12:00

Anatomy of ROCgdb (GDB for AMD GPUs)

New and Upcoming Hardening Features in GCC

12:00 - 13:00

Lunch (provided)

13:00 - 14:00

Morello GCC: bringing CHERI capabilities to the GNU toolchain

If-Conversion for a Partially Predicated VLIW Architecture

14:00 - 15:00

Improving glibc with Restartable Sequences

Sphinx documentation BoF

15:00 - 15:30

Coffee break

15:30 - 16:30

GNU poke and the GNU Toolchain

IBM zSystems BoF

16:30 - 17:30

Value Numbering in GCC

Arm/AArch64 BoF

Lightning talks


9:30 - 10:00

Registration, tea & coffee

10:00 - 11:00

* GCC Intrinsic & Auto-Vectorization for RISC-V Vector Extension

The GNU C Library BoF

11:00 - 12:00

gprofng: The next generation GNU profiling tool


12:00 - 13:00

Lunch (provided)

13:00 - 14:00

Update on the Rust front-end


14:00 - 15:00

ABI analysis, libabigail and CTF

Upstreaming the Rust front-end BoF

15:00 - 15:30

Coffee break

15:30 - 16:30

Redesigning GDB's Ctrl-C handling

In-process unwinding BoF

16:30 - 17:30

CTF Frame format support in the GNU Toolchain


18:30 - 22:00

Boat trip and dinner


9:30 - 10:00

Registration, tea & coffee

10:00 - 11:00

GCC Steering Committee Q&A

11:00 - 12:00

Ranger update

BoF: Diversity and Inclusion

12:00 - 13:00

lunch (provided)

13:00 - 14:00

OpenACC, OpenMP, Offloading and GCC

BoF: Sourceware GNU Toolchain Infrastructure and beyond

14:00 - 15:00

Security Improvement in the GNU Toolchain

BoF: OpenMP, OpenACC & Offloading

BoF: GNU Toolchain Infrastructure and the GTI project

Afternoon tea & coffee

* indicates a talk which will be given remotely.


Below is the list of confirmed talks, BoFs and Q&A sessions. If you would like to present a talk or lead a BoF/Q&A session, please see the instructions above.


ABI analysis, libabigail and CTF

Speaker(s): Guillermo E. Martinez Quezada

libabigail is a library and a set of tools to extract, constructing, manipulating, serializing, comparing and de-serializing ABI-relevant artifacts from binary files, providing detailed information about their differences and it helps to build tools to infer interesting conclusions about these differences.

libabigail is able to read ELF, DWARF, & XML files to build an IR of the ABI. New support was added to now be capable to read CTF debug information from ELF binaries including the linux kernel image and linux kernel modules.

The Compact C Type Format (CTF) is a way of representing information about a binary program; it can be seen as a simpler alternative to the widely used DWARF format.

One of the major improvement is the time spent to extract the ABI from binary files using the libabigail CTF reader compared with DWARF reader in libabigail. For example extracting ABI information from the Linux kernel using DWARF reader takes ~3m40s and and using CTF reader takes 0m50s, this is up to ~4.5 time less time

In this talk we will show how we added support for a new reader in libabigail and how the type information is used to derive libabigail's notion of an ABI. Then we will discuss about the concept of ABI, how it is implemented in tools, and hint some ways the toolchain could be leveraged to provide additional useful information to these tools, for instance some gcc attributes modify the ABI but they are not represented in libabigail IR objects and in some cases neither in DWARF/CTF debug information.

Anatomy of ROCgdb (GDB for AMD GPUs)

Speaker(s): Simon Marchi, Pedro Alves, Zoran Zaric, Lancelot Six, Laurent Morichetti, Tony Tye

Slides: Anatomy of ROCgdb.pdf

ROCgdb is a GDB port capable of debugging ROCm applications which offload compute kernel workloads on AMD GPUs. The presentation will provide an overview of the distinctive features of GPU architectures and how they are exposed to the user via the HIP (Heterogeneous Interface for Portability) programming model.

Providing a fluid debugging experience that matches the user's view of the program in this programming model requires major changes in the design of GDB. Some of the key features and design changes of ROCgdb are:

  • Presentation of compute kernel threads under the same inferior as host threads.
  • Support for SIMT lanes and thread divergence in many GDB commands.
  • Support for [extensions to DWARF for Heterogenous Debugging]( allowing compilers to describe complex location descriptions not supported by DWARF 5, and more.

  • Support for address spaces, distinct from source level address classes.
  • Generalization of the "commit-resumed" concept to avoid unnecessary resumptions.
  • Redesign of how Ctrl-C is handled in GDB.

We will discuss some technical details behind these features. Some of them are considered complete, others still contain temporary solutions that need to be taken care of. We will also provide an update about the upstreaming efforts.

CTF Frame format support in the GNU Toolchain

Speaker(s): Indu Bhagat

Slides: Cauldron_2022_ctf_frame.pdf

CTF Frame format compactly represents the minimal necessary unwind information needed for virtual stack unwinding: Canonical Frame Address (CFA), Frame Pointer (FP), and the Return Address (RA). Currently, it supports AMD64 and AAPCS64 ABIs. CTF Frame information is made available to the users via an allocatable, loadable section named .ctf_frame in a segment PT_GNU_CTF_FRAME of its own.

CTF Frame format is designed for those applications which need fast, online stack unwinding. In this talk, we will discuss the specification of the CTF Frame format and implementation of it in the GNU Toolchain. The assembler generates the CTF Frame unwind information using the existing CFI directives. The linker merges the input .ctf_frame sections and places the output .ctf_frame section in a segment of its own. Support has also been added for textual dump of the .ctf_frame section via readelf and objdump.

GCC -fanalyzer update

Speaker(s): David Malcolm

Slides: 2022-Cauldron-analyzer-talk.pdf

In this talk I'll give an update on the status of -fanalyzer, the static analysis option I added to GCC in 2020. I'll talk about:

  • serialization of static analysis results (and of other diagnostics),
  • my efforts at using -fanalyzer on the Linux kernel,
  • what's new in -fanalyzer for GCC 13, and
  • possible future directions for the analyzer

GCC Intrinsic & Auto-Vectorization for RISC-V Vector Extension

Speaker(s): Juzhe Zhong (RiVAI Technologies), Xi Wang (RIOS Lab, Tsinghua University), Zhangxi Tan (RiVAI Technologies & RIOS Lab, Tsinghua University)

RISC-V Vector (RVV) is an instruction-set architecture extension that provides RISC-V vectorization support. It enables RISC-V processors to process data arrays, alongside traditional scalar operations in the SIMD manner to enhance the performance via data-level parallelism.

The optimized compiler support is critical to enhance the applicability and portability of RISC-V Vector extension. However, existing RVV implementations in GCC toolchain can not effectively satisfy such need. Therefore, we introduce an open-source RVV GCC design and implementations including the 80K intrinsic and complete auto-vectorization support of int8,int16,int32,int64,fp16,fp32,fp64. Our GCC RVV implementation outperforms the LLVM RVV support by 20% (up to 50%) based on our evaluation results. Our efforts have been included in the RISC-V foundation repository:

In this presentation, we will cover the following topics:

  1. RVV basic concept.
  2. RVV intrinsic implementation.
    1. RVV intrinsic builtin framework in GCC.
    2. RVV insert-vsetvli Pass implementation and optimization (In RVV, almost all the instruction needs compiler to insert vsetvli instruction automatically).
  3. Auto-vectorization using RVV instruction.
    1. VLA (Vector length agnostic) auto-vectorization.
    2. VLS (Vector length specific) auto-vectorization.
    3. The implementation details of vector loop condition control using RVV vsetvli instruction mechanism.
    4. Add RVV related auto-vectorization standard pattern to optimize auto-vectorization.
  4. Introduction of testcases for RVV feature (intrinsic and auto-vectorization). 1 .RVV GCC auto-vectorization performance data of some program project for example: tensorflow-micro (spike instruction count).
  5. RVV GCC support status including supported features and TODO features.

GNU poke and the GNU Toolchain

Speaker(s): Jose E. Marchesi, Mohammad-Reza Nabipoor

It's been two years since GNU poke (the extensible editor for structured binary data) was first published during the GNU Tools Cauldron 2019 in Montreal. During this time poke development has progressed very fast, and we are already preparing the third major release of the program (poke 3.x) which is scheduled for the end of the summer.

GNU poke is distributed in the form of a shared library (, a daemon (poked) and a command-line application (poke). The shared library, which provides the incremental compiler for the Poke language and the Poke Virtual Machine (PVM), is specifically designed to integrate poke in other applications.

In this talk we will be showing two examples of this that show how poke can be leveraged to improve the GNU Toolchain:

First, we integrated poke in GDB, the GNU debugger. This makes it possible for the GDB users to poke at the inferior's memory. The integration includes the ability of translating GDB types into Poke types. But a particularly useful use-case is when we need to poke at the contents of buffers in the inferior's memory for which we don't have type information in the debugger; an example of this is payloads in network packages:

   : (gdb) poke load tcp
   : (gdb) poke var p = TCP_Packet @ $addr::my_buffer
   : (gdb) poke p.hdr.bit2 = 0

Then there is the integrating of poke in GAS, the GNU assembler. This takes the form of a new assembler directive: `.poke'. This directive can then be used to assemble arbitrarily complex data structures. For example, instead of this:

   : .section .text
   : .set softfloat
   : .ascii "PS-X EXE"
   : .byte 0, 0, 0, 0, 0, 0, 0, 0
   : .word main
   : .word 0
   : .word 0x80010000
   : .word image_size
   : .word 0,0,0,0
   : .word 0x8001FFF0
   : .word 0,0,0,0,0,0
   : .ascii "Sony Computer Entertainment Inc. for zid"

We can write:

   : .section .text
   : .set softfloat
   : .poke load psxexe
   : .poke var s = "Sony Computer"
   : .poke PS_X_EXE { start = $main, size = $image_size, vendor = s }

Both GDB and GAS can of course use the many existing pickles around. In the talk, we would like to discuss and explore other toolchain areas/programs where poke may be useful, like generating testing data, documenting the several binary formats implemented by the tools, etc.

gprofng: The next generation GNU profiling tool

Speaker(s): Ruud van der Pas, Vladimir Mezentsev

In this talk we present an overview of gprofng, the next generation profiling tool for GNU/Linux. In March 2022, gprofng received the approval for inclusion in binutils and we are planning for gprofng to be part of 2.39 release.

This profiler has its roots in the Performance Analyzer from the Oracle Developer Studio product. Gprofng is a standalone tool however and specifically targets GNU/Linux. It includes several tools to collect and view the performance data. Various processors from Intel, AMD, and Arm are supported. The focus of gprofng is on applications written in C, C++, Java, and Scala. For C/C++ we assume GCC has been used to build the code. In the case of Java and Scala, OpenJDK and compatible implementations are supported.

Among other things, another difference with the widely known gprof tool is that gprofng offers full support for shared libraries and multithreading using Posix Threads, OpenMP, or Java Threads. Unlike gprof, gprofng can also be used in case the source code of the target executable is not available. Gprofng also works with unmodified executables. There is no need to recompile, or instrument the code. By profiling the production executable it is ensured that the profile reflects the actual run time behaviour and conditions of a production run.

After the data has been collected, the performance information can be viewed at the function, source, and disassembly level. Individual thread views are supported as well. Through command line options, the user specifies the information to be displayed. In addition to this, a simple, but yet powerful scripting feature can be used to produce a variety of performance reports in an automated way. This may also be combined with filters to zoom in on specific aspects of the profile. For example, it is very easy to zoom in on one or more threads, but also to compare the behaviour across threads.

One of the very powerful features of gprofng is the ability to compare two or more profiles. This allows for an easy way to spot regressions, or find scalability bottlenecks for example.

Two recent additions are the support for html based browsing of the profile information, and a GUI to graphically display and analyze the data.

The first of these features uses gprofng to generate an html based directory structure. This needs to be done on the target platform, but the results can be displayed and navigated on any platform using a standard browser. It is not necessary for gprofng to be available when browsing the results.

In case a more in-depth analysis is desired, the gprofng GUI is ideally suited to drill deeper into the data. In addition to display the basic profiling information, it also offers several views to provide more insight into the dynamic behaviour of the application. For example, to view the colour coded call stacks as a function of time. It also has full support to graphically compare profiles. The built-in filters can be used to zoom in on a specific time window and/or a subset of the threads used. If needed, the user can also define customized filters.

In the talk, we start with a description of the architecture of the gprofng tools suite. This is followed by an overview of the various tools that are available, plus the main features. A comparison with gprof will be made, but the bulk of the talk consists of examples to show the functionality and features. This includes the html functionality and GUI. We conclude with the plans for future developments.

Improving glibc with Restartable Sequences

Speaker(s): Mathieu Desnoyers

glibc 2.35 introduced support for the Restartable Sequences (rseq) system call in February 2022. It is initially used to speed up sched_getcpu(). There are various areas of glibc which can benefit from using rseq, the main contenders being the memory allocator, statistics counters, and the getcpu(2) API. Other projects such as tcmalloc have already started using rseq.

This presentation will discuss the extensions recently proposed to the rseq system call, how they impact glibc use-cases, and more generally which additional glibc use-cases can benefit from rseq and whether further extensions are needed.

If-Conversion for a Partially Predicated VLIW Architecture

Speaker(s): Benoît Dinechin

Slides: If-Conversion for a Partially Predicated VLIW Architecture

Kalray are producing manycore processors based on 'KVX' cores that implement a modern VLIW architecture ('vector-scalar' ISA as in IBM POWER, can be compiled like on-order superscalar, no VLIW templates). The main C/C++ compiler is a retargeting of GCC 10.

The talk proposal is about how to achieve aggressive if-conversion with the existing GCC ifcvt infrastructure. Below I outline what was done, and if of interest will reformat as an abstract for the talk.

The main challenge is that the KVX implements a Fisher-style VLIW architecture, which does not have a fully predicated ISA. Instead, only conditional load, store, and register moves are available. However one should note that most ISAs have a conditional register move, and from that it is possible to emulate conditional load and stores (conditional move of load returned value in a temporary, and conditional move of store address to a don't care stack location). So the talk is relevant to if-conversion even for cores that do not have superscalar implementation with hardware speculative execution.

In our case, aggressive if-conversion involves the predication of data moves, and the speculation of arithmetic instructions operating on registers without other side-effects.

The current GCC ifcvt infrastructure operates in three passes:

  • CE1 for conditional register moves before combine
  • CE2 for conditional register moves after combine
  • CE3 for fully predicated ISA after reload

In particular, if-conversion of load and stores can only be performed by CE3.

Our approach is to have the ifcvt infrastructure do normal CE1 and CE2 conversion to conditional moves, and in addition extend CE2 to prepare for speculated execution and predicated execution by CE3. Then in CE3 the (cond_exec ) patterns proposed by (cond_exec_process_insns) and the insns marked for speculative execution enable further if-conversion. For this, the TARGET_HAVE_CONDITIONAL_EXECUTION implementation returns the value of reload_completed.

During the CE2 step where we prepare for CE3, for each instruction in a then_bb or else_bb there are four cases cases to consider:

  1. the instruction can be cond_exec as is: register moves, memory load and stores whose addressing mode exist in the conditional form => provide a cond_exec variant of the pattern in machine description

  2. memory load or store whose addressing mode is too complex for the conditional form => provide a parallel pattern with the original one and a clobber of a pseudo-register that will be used to compute the address

  3. arithmetic instructions without side-effects whose SET_DEST register is not live-out => mark the insn as speculative

  4. arithmetic instructions without side-effects whose SET_DEST register is live-out => provide a parallel pattern with the original one and a clobber of a pseudo-register that will be used in a conditional move

The patterns with the (parallel [(set ...) (clobber ...)]) clobber a temporary (pseudo-)register instead of a (scratch) because we need to ensure that register allocation will not use a hard registers that carry a value across blocks of the IF-THEN-ELSE-JOIN (or IF-THEN-JOIN) hammock. For each of these temporary registers we insert a (clobber ...) at the end of test_bb and a (use ...) at the start of join_bb to make them interfere with the non-local variables. In addition, we include a (use ..) of the tested register at the end of then_bb and else_bb so it will be available for CE3 predication in these blocks.

Now for the patterns used by CE3 we rely on split after reload and before sched2 (split4) to:

  • either undo the wrapping of (parallel [(set ...) (clobber ...)]) done at CE2 in cases 1) and 3) by reverting to the original (set ..) pattern if the if-conversion of a particular hammock was not successful.
  • or in case 1), split the (cond_exec ...) produced by (cond_exec_process_insns) into computing the address into the temporary register, then feeding it into the conditional form of the load store; the split preparation emits this address computation.
  • or in case 2), remember that the insn was deemed speculative in CE2, and have IFCVT_MODIFY_INSN return the original pattern instead of the one proposed by (cond_exec_process_insns).
  • or in case 3), where the (parallel [(set ...) (clobber ...)]) done in CE2 has been wrapped into a (cond_exec ..) by (cond_exec_process_insns), split into the original (set ...) targeting the temporary, followed by (cond_exec ...) move of this temporary into the original SET_DEST of the insn.

Although it appears robust and significantly improves performance on the KVX, currently this work has a few issues left:

  • Flagging insns as speculative in CE2 so that CE3 (cond_exec_process_insns) does not wrap them in (cond_exec ...) is done by adding and checking REG_NONNEG, otherwise not used on our port. This is a hack.
  • Creating the (cond_exec) patterns for the case 3) is tedious and error-prone so was automated by an ad-hoc script. Indeed, (define_cond_exec) does not apply because the resulting (cond_exec) should be a (define_insn_and_split) for cases 1) and 3). Same for (define_subst ...).

This work seems original, as most of published if-conversion work operates either on pseudo-registers or on SSA variables, e.g. see my survey of if-conversion techniques in CC'14

Among the GCC 10 ports that exploit CE3, the FRV achieves CE3 if-conversion by scanning the register allocated code for available hard registers, then use them for reassigning CC registers and to compute temporary values such as addresses for conditional load/store. By contrast, we reserve hard registers for temporary computations by adding in CE2 (clobber ...) to the patterns of CE3 candidates, as the KVX has a register-rich ISA.

Morello GCC: bringing CHERI capabilities to the GNU toolchain

Speaker(s): Alex Coplan , Szabolcs Nagy

Slides: morello-gcc-cauldron-2022.pdf

Morello is a research program led by Arm and funded by the UK government’s Industrial Strategy Challenge Fund (ISCF) Digital Security by Design (DSbD) programme in which CHERI capabilities are introduced in an experimental fork of the Armv8-A architecture. These capabilities enable fine-grained memory protection and highly scalable software compartmentalization. Arm has designed a CPU and industrial demonstrator board which implements the Morello architecture.

As part of this work, we have been developing a port of the GNU toolchain to Morello. In this talk, we will introduce CHERI and Morello, dive into some of the far-reaching implications of introducing capabilities to the toolchain, and present what has been achieved to date.

New and Upcoming Hardening Features in GCC

Speaker(s): Alexandra Oliva

This talk will cover the design and implementation of several hardening features added in GCC 12, or yet to be contributed: registers and stack scrubbing, hardening of conditionals, control flow redundancy, and hardened booleans for Ada and C. It will also discuss challenges in the pursuit of target-independent implementations, and of testing features disabled by default.

OpenACC, OpenMP, Offloading and GCC

Speaker(s): Tobias Burnus, Thomas Schwinge, Andrew Stubbs

Slides: OpenMP-OpenACC-Offload-Cauldron2022-1.pdf

A short intoduction to OpenACC and OpenMP, their implementation status in GCC and features to be extended or still to be implemented of OpenACC up to 3.2 and OpenMP up to 5.2 – with the next releases/previews expected for later this year.

Additionally, an introduction in how offloading to an accelerator/GPU device is implemented in GCC, what is implemented there and what is missing or should be improved.

Ranger update

Speaker(s): Aldy Hernandez

Slides: 2022-ranger-update-Cauldron.pdf

This talk will give a summary of what's been going on in ranger land, and what we plan to include in next year's GCC 13. We will also briefly touch on what we would like to work in the future (GCC 14 and beyond).

Some of the upcoming things for this release include: (a) a range type agnostic framework, (b) an initial implementation for floating point range (c) fine grained global ranges (d) pointer ranges (e) enablement of ranger VRP for all VRP clients (f) removal of legacy VRP, plus other things....

Redesigning GDB's Ctrl-C handling

Speaker(s): Pedro Alves

Slides: Ctrl-C redesign.pdf coverage:

Currently, on GNU/Linux GDB, it is not possible to use Ctrl-C to interrupt programs that block or ignore SIGINT. You type Ctrl-C, but nothing happens, the debug session gets stuck, and sometimes it is not possible to get back the prompt.

This session will explain why that does not work, why fixing this turns out to be important for the incoming AMD GPU target, and what is the plan to fix it. We will go over how GDB currently handles Ctrl-C for the different targets GDB supports, and for native GNU/Linux more in detail. We will talk about terminal sessions, session leaders, process groups, terminal settings, pseudo-terminals, controlled I/O flushing, ptrace, how GDB stops programs, and more.

Security Improvement in the GNU Toolchain

Speaker(s): Qing Zhao, Siddhesh Poyarekar

Multiple new security improvements were added to the latest GNU toolchain releases. These include stack variables auto-initialization in the GCC middle-end, __builtin_dynamic_object_size support in C and C++ frontends, source fortification (_FORTIFY_SOURCE) level 3 support in GLIBC, straight line speculation mitigation in the GCC X86 backend, and many other improvements.

The focus of this talk is on stack variables auto-initialization,__builtin_dynamic_object_size in GCC12, and source fortification (_FORTIFY_SOURCE) level 3 in GLIBC 2.34. We will also provide more information on several other security features in the latest GNU toolchain.

Starting from GCC12, GCC can initialize all stack variables implicitly, including paddings, through a new option -ftrivial-auto-var-init. This is intended to eliminate all classes of uninitialized stack variable flaws. Lack of explicit initialization will still warn when -Wuninitialized is active. The initial patch has been committed in an early stage of GCC12 in September 2021, followed by bug fixes and enhancement to complete the feature. The Linux Kernel has been configured to use this new feature to improve its security since then.

The _FORTIFY_SOURCE macro has been a key mitigation feature in the GNU C Library, supported by the __builtin_object_size builtin function implemented in GCC. The key limitation of this feature was that it relied on a constant size estimate for fortified objects and when one wasn't available, the objects would remain unfortified.

GLIBC 2.34 added support for a new fortification level (_FORTIFY_SOURCE=3), which uses the __builtin_dynamic_object_size builtin function, expanding the scope of fortification coverage to situations where a variable size estimate for objects can be computed. The __builtin_dynamic_object_size builtin was implemented in GCC 12, allowing Linux based distributions to be bootstrapped with this new fortification level.

In addition to the above major security improvements in the GNU toolchain, straight line speculation (SLS) mitigation for function return and indirect jump is supported on X86, "wipe call-used registers on return" (-fzero-call-used_regs) was enhanced to include more targets, and better code sequence on X86. The Static Analyzer also gained a set of nice improvements.

In the talk we provide a high-level overview of these new security features. This includes a description of the motivation, major challenges, new interfaces to the users, current status of the features, the performance impact, and existing known issues. We conclude with a sketch of future direction and further improvements of these security features under consideration.

Update on the Rust front-end

Speaker(s): Philip Herron, Arthur Cohen, David Faust

This talk will show the current state and progress of the front-end in terms of the upstreaming process and quality. A focus will be on managing the project, from patches to bug triage. Each author will discuss their area of interest, areas we can improve and ideas for the future.

Value Numbering in GCC

Speaker(s): Richard Biener

The talk presents the history around value numbering in GCC, focusing on most recent development providing a region-aware scalable utility.

Slides: 2022-Cauldron-Value-Numbering.pdf

Lightning Talks

Adding Zc* support to the GNU tool chain

Speaker(s): Nandni Jamnadas (speaker), Chen Jiawei, Sinan Lin, YuLong, Charlie Keaney, Pietra FT Madio

Adding a RISC-V extension to the GNU tool chain is becoming more routine. However there are challenges in supporting an architecture that is so configurable, and where the design is done in public, with many changes before stability is reached. Zc* itself breaks into a set of 7 sub-extensions (or possibly 10 sub-extensions), depending on how you count. It is a superset of the original C extension, leading to a challenging set of constraints on what combinations of extensions are permitted. There are associated demands on testing, not just of the individual instructions, but of the various possible combinations of instructions.

In this lightning talk we'll share the experience of a collaborative effort to add support for Zc* 0.70.4 support to the GNU tool chain between the Programming Languages and Compiler Team of the Chinese Academy of Sciences and Embecosm. We hope the experience will be of use to others adding extensions. We will conclude with the initial assessment of Zc* impact on code size using the Embench benchmark suite.


Arm/AArch64 BoF

Speaker(s): Richard Earnshaw

The Arm and AArch64 BoF is an open session for discussing your issues and concerns on anything Arm related in the GNU toolchain. There is no fixed agenda!

We'll probably start with a brief overview of the work done in the past year and then focus on whatever seems to be the most interesting item within the group. If you have specific issues or uestions that you wish to raise, it might help if you can notify us in advance so that we can try to ensure that there is time to cover it.

BoF: OpenMP, OpenACC & Offloading

Speaker(s): Tobias Burnus, Jakub Jelinek, Thomas Schwinge, Andrew Stubbs

Slides: BoF-OpenMP-OpenACC-Offloading-Cauldron2022.pdf

BoF to discuss topics related to concurrency and offloading work onto accelerators.

In particular, implementation of missing OpenMP 5.0 to 5.2 and OpenACC 2.7 to 3.2 features and their support on AMD and Nvidia devices. Further more improving the performance both on the device-specific part as also offloading/Open*-aware optimizations, extending the offloading format to support multiple -march/-misa per offload type, improving the diagnostic, and extending the documentation.

Related topics and trends can also be discussed, be it base language concurrency features, offloading without using OpenMP/OpenACC, other accelerators.

Diversity and Inclusion

Speaker(s): Nathan Sidwell

A discussion on diversity and inclusivity and how GCC can do better.

IBM zSystems BoF

Speaker(s): Ilya Leoshkevich, Andreas Arnez

Discuss topics related to the s390x / IBM zSystems toolchain, including support for the new z16 machine:

  • New hardware and CPU facilities; AI accelerator.
  • Binutils / gcc support for the above.
  • Valgrind challenges.

In-process unwinding BoF

Speaker(s): Florian Weimer

GCC 12 removed a multi-threading scalability bottleneck in the libgcc unwinder (for static unwinding data). In this session, we plan to discuss future performance provements: how to land the dynamic frame registration in trunk, how to address some low-hanging fruit in DWARF processing. We an also discuss reliability improvements for avoiding out-of-stack reads if there is interest.

BoF: Sourceware GNU Toolchain Infrastructure and beyond

Speaker(s): Mark Wielaard, Frank Eigler

The Sourceware infrastructure is continually improving. Just like our other services, such as bugzilla, mailinglists and git repos, we like to provide zero maintenance infrastructure for tracking and automation of patches, testing and analyzing testresults. This BoF is for everybody who likes to discuss (and wants to help with) automating the infrastructure to make contributing to our projects more fun and more productive.

Topics to discuss include the shared buildbot [1]. Whether we need more/other arches/distro support. Which builders are most beneficial to projects. How buildbot should report issues. Whether to use the buildbot to automate other tasks like updating documentation, websites, generate release tars or updating bugzilla. How to use git user try branches. Taking advantage of the Bunsen [2] testrun cluster analysis, per-testrun testcase search/browse engines, search operators, testsuite summary (vs detail) grids. Patch tracking using patchwork [3] integrated with buildbot and the CICD trybot [4]. How to use the sourcehut mirror [5]. And anything else that would make you more productive and happy contributing.


Slides: html markdown

GNU Toolchain Infrastructure and the GTI project:

Speaker(s): Carlos O'Donell, David Edelsohn

Slides: GNU Toolchain Infrastructure.pdf


Speaker(s): Pedro Alves

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

The GNU C Library BoF

Speaker(s): Carlos O'Donell, Florian Weimer

Slides: GNU Tools Cauldron 2022 - The GNU C Library BoF.pdf

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.

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 glibc 2.37 and what work needs to be done between September 2022 and February 2023.
  • Planning for glibc 2.38 and what work needs to be done between February 2023 and August 2023.
  • Status of kernel syscall wrappers.
  • Status of Patchwork pre-commit CI/CD.

... and more.


Speaker(s): Jan "Honza" Hubicka

A discussion of anything to do with Link Time Optimzation


Speaker(s): Kito Cheng, Jeremy Bennett, Palmer Dabbelt

An opportunity to discuss everything around the RISC-V tool chain.

  • A bunch of new extensions are in flight, I'm sure there'll be stuff to talk about there -- whether it's for stuff that's ratified like B and V or for stuff that's still in draft like CFI (which may be another ABI).
  • Vendor extensions. We'll likely have some simple stuff in by that point, but I very much doubt we've got anything concrete for the more complicated bits.
  • This memory model stuff is likely to drag on for a while, doubly so if there's ABI issues.
  • No idea where we'll stand WRT the psABI stuff, but I bet there'll be something to talk about.
  • Also no idea if the proflies stuff will have gone anywhere by then, but again there'll likely be stuff to talk about.

The Sphinx Documentation BoF

Speaker(s): Martin Liška

A discussion about the current GCC's documentation and how can we improve it with a more modern documentation format called Sphinx. I'm going to make a demo presentation of the migrated documentation and we will discuss possible benefits and drawbacks.

Slides: cauldron-2022-docs-bof.pdf

Upstreaming the Rust front-end BoF

Speaker(s): Philip Herron, Arthur Cohen, Davd Faust

This BOF will continue from the talk to open a more in-depth discussion about the upstreaming process and how this is going. What can we do better?


None submitted

Q&A Sessions

GCC Steering Committee Q&A

Speaker(s): David Edelsohn

Let's talk about GNU Toolchain governance with the GCC Steering Committee, and GLIBC, GDB and Binutils Stewards!

Mailing lists

  1. Abstract submissions, registration, administrivia questions:

  2. Announcements and discussions related to the conference: .

Workshop description

We are pleased to announce another gathering of GNU tools developers. The basic format of this meeting will be similar to the previous meetings but this year we are bringing a hybrid element to the event. If you are unable to join us physically there will be the ability to present and interact via videoconference, but we would like to see as many of you face to face after what has been a challenging few years.

The purpose of this workshop is to gather all GNU tools developers, discuss current/future work, coordinate efforts, exchange reports on ongoing efforts, discuss development plans for the next 12 months, developer tutorials and any other related discussions.

We will meet again at the Lesser Town Campus of Charles University in Prague (Malostranske Namesti 25, Prague, Czech Republic map1, map2). (The same location as of GNU Tools Cauldron 2017, GNU Tools Cauldron 2015 and GNU Tools Cauldron 2012).

We are inviting every developer working in the GNU toolchain: GCC, GDB, binutils, runtimes, etc. In addition to discussion topics selected at the conference, we are looking for advance submissions.

If you have a topic that you would like to present, please submit an abstract describing what you plan to present. We are accepting four types of submissions:

Slots are 1 hour long, apart from lightning talks, which are 10 minutes long.

Note that we will not be doing in-depth reviews of the presentations. Mainly we are looking for applicability and to decide scheduling. There will be time at the conference to add other topics of discussion, similarly to what we did at the previous meetings.

To register your abstract, send e-mail to .

Your submission should contain the following information:

If you intend to participate, but not necessarily present, please let us know as well. Send a message to stating your intent to participate. Please indicate your affiliation, dietary requirements and t-shirt size.

Travel Grants

The GNU Toolchain Fund sponsors developer travel to attend the GNU Cauldron. Travel grants cover some or all of travel related expenses.

Individuals should email information about their participation in the GNU Toolchain, interests, experience, an estimated budget, and any sponsors in the GNU Toolchain community to

The deadline to submit a request is 31 July 2022.

Code of Conduct

All participants are expected to abide by the conference Code of Conduct. As in 2019, we shall use the British Computer Society Open Source Specialist Group Code of Conduct.

Since the event, it became clear we required a Code of Conduct committee to address issues raised under the Code of Conduct. The following are the members of the Code of Conduct committee:

Reports: GNU Tools Cauldron 2022 Code of Conduct Transparency Report


The conference venue can be conveniently reached by the public transport, either by Metro (subway, underground train) line A (green line), to the station of Malostranská and then by a short walk, or by the tramway lines No. 12, 20 or 22 to the stop of Malostranské náměstí. The tramway stop is situated right across the square to the conference venue. A public traffic schemes can be downloaded at

Because of the location just in the center of Prague, it is easy to check lodging options on common booking sites, like

None: cauldron2022 (last edited 2023-08-16 21:06:53 by CarlosODonell)