{"$schema": "https://c3voc.de/schedule/schema.json", "generator": {"name": "pretalx", "version": "2026.3.0.dev0", "url": "https://conf.gnu-tools-cauldron.org"}, "schedule": {"url": "https://conf.gnu-tools-cauldron.org/prg26/schedule/", "version": "0.12", "base_url": "https://conf.gnu-tools-cauldron.org", "conference": {"acronym": "prg26", "title": "GNU Tools Cauldron 2026", "start": "2026-10-02", "end": "2026-10-04", "daysCount": 3, "timeslot_duration": "00:05", "time_zone_name": "Europe/Prague", "colors": {"primary": "#042c62"}, "rooms": [{"name": "Refectory (S 120)", "slug": "6328-refectory-s-120", "guid": "c0a50f2a-c945-5ac9-84d4-f66ddcbd98a0", "description": "Friday only room.", "capacity": 200}, {"name": "Room S 9", "slug": "6330-room-s-9", "guid": "85df697a-8b52-567f-bfb5-bffc6824c502", "description": null, "capacity": 118}, {"name": "Room S 5", "slug": "6329-room-s-5", "guid": "01e81035-f949-53e4-88d1-7c9e569b863b", "description": null, "capacity": 118}, {"name": "Room S (Floor 3)", "slug": "6384-room-s-floor-3", "guid": "c5e444fc-ad72-56fc-8d01-383185f251ce", "description": null, "capacity": 118}, {"name": "Room S 6 (Small, 24 people)", "slug": "6331-room-s-6-small-24-people", "guid": "fe407bf7-d08e-5283-9aff-b3a5f9d3e51c", "description": "Small 24 person room for spill over BoF discussions.", "capacity": 24}, {"name": "Room S 11 (Small, 24 people)", "slug": "6373-room-s-11-small-24-people", "guid": "d44bf21f-5c11-5040-87e6-e4e6c6fd1ea1", "description": "Small 24 person room for spill over BoF discussions.", "capacity": 24}], "tracks": [{"name": "Talks", "slug": "7121-talks", "color": "#00e01f"}], "days": [{"index": 1, "date": "2026-10-02", "day_start": "2026-10-02T04:00:00+02:00", "day_end": "2026-10-03T03:59:00+02:00", "rooms": {"Refectory (S 120)": [{"guid": "5a2b4e72-be3c-59d7-86d4-17cc5e39619e", "code": "MHWKXJ", "id": 103804, "logo": null, "date": "2026-10-02T09:00:00+02:00", "start": "09:00", "end": "2026-10-02T10:00:00+02:00", "duration": "01:00", "room": "Refectory (S 120)", "slug": "prg26-103804-demand-bits-scev-assumptions-and-other-fun", "url": "https://conf.gnu-tools-cauldron.org/prg26/talk/MHWKXJ/", "title": "Demand Bits, SCEV Assumptions and Other Fun.", "subtitle": "", "track": null, "type": "Talk", "language": "en", "abstract": "This talks briefly covers several (mostly random) things I worked on in the middle end this year:\n - Demand-bit backpropagation\n - Reassociation of plus/mult trees\n - Assumptions for unsigned scalar evolution\n - Dependent register constraints\n - Vector predicate RTL representation\n\nThe first two originated in a small, mostly stupid benchmark snippet but turned out to have real value.\nUnsigned assumptions help vectorizing SPECint 2016's xz.\nDependent register constraints and the vector predicate RTL representation help riscv in particular.", "description": "", "recording_license": "", "do_not_record": false, "persons": [{"code": "BUFWQT", "name": "Robin Dapp", "avatar": null, "biography": "Robin is working on the riscv target with a focus on vectorization and other middle-end topics.", "public_name": "Robin Dapp", "guid": "3f283bb2-90fb-53f7-8df5-e1ca78482ef8", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/BUFWQT/"}], "links": [], "feedback_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/MHWKXJ/feedback/", "origin_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/MHWKXJ/", "attachments": []}, {"guid": "e878ee9e-8caf-58bd-b7c5-beab17244f6c", "code": "LCFMB9", "id": 105120, "logo": null, "date": "2026-10-02T10:30:00+02:00", "start": "10:30", "end": "2026-10-02T11:30:00+02:00", "duration": "01:00", "room": "Refectory (S 120)", "slug": "prg26-105120-glibc-malloc-experiments-and-future-direction", "url": "https://conf.gnu-tools-cauldron.org/prg26/talk/LCFMB9/", "title": "glibc malloc experiments and future direction", "subtitle": "", "track": null, "type": "Talk", "language": "en", "abstract": "This session covers some recent experiments with the `malloc` implementation of the GNU C Library to improve performance and memory usage.\n\nThe 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:\n\n- batching `free`s, with and without sorting deallocations by address\n- surface-level and deep consolidation of chunks as they are evicted from the thread cache\n- putting per-thread `malloc` metadata into the thread control block (TCB)\n- more prompt deallocation of unused heap (64 MiB) segments\n- using an array for the unsorted bin (instead of a doubly linked list), greatly improving cache locality\n- replacing the ad-hoc tree for large bin sizes with a proper red-black tree\n- using linear address masking (LAM) to implement packed 32-byte allocations\n- optimizing tag management without a dedicated tag manipulation ISA\n\nThe purpose of this session is to present these experiments and gather feedback what optimizations are most promising and should be submitted for upstream inclusion.", "description": "We would like to encourage attendees to share their own results and observations.", "recording_license": "", "do_not_record": false, "persons": [{"code": "CSEFJY", "name": "Florian Weimer", "avatar": null, "biography": "Florian is a long-time contributor to the GNU toolchain, particularly glibc. He currently serves as the glibc tech lead on the Red Hat Platform Tools team.", "public_name": "Florian Weimer", "guid": "2df8e974-0ce9-5200-8ea0-28c5d41b1e69", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/CSEFJY/"}], "links": [], "feedback_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/LCFMB9/feedback/", "origin_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/LCFMB9/", "attachments": []}, {"guid": "4928390c-608c-5736-8eca-338b7462e92c", "code": "CNN8WR", "id": 103506, "logo": null, "date": "2026-10-02T11:30:00+02:00", "start": "11:30", "end": "2026-10-02T12:00:00+02:00", "duration": "00:30", "room": "Refectory (S 120)", "slug": "prg26-103506-c-support-in-gcc-static-analyzer-progress-and-future-plans", "url": "https://conf.gnu-tools-cauldron.org/prg26/talk/CNN8WR/", "title": "C++ Support in GCC Static Analyzer: Progress and Future Plans", "subtitle": "", "track": null, "type": "Talk (Short)", "language": "en", "abstract": "This presentation covers:\n- how GCC's Static Analyzer works\n- progress on C++ support in the Static Analyzer after my GSoC project\n- future plans for continuing improvements to C++ support.\n\nRelated writeup can be found at: https://riogu.github.io/posts/gsoc-2026/", "description": "This talk is a mix between covering my GSoC project and sharing it\nwith the community, and talking about the state of the project in general.", "recording_license": "", "do_not_record": false, "persons": [{"code": "EJ3DN3", "name": "Egas Ribeiro", "avatar": "https://conf.gnu-tools-cauldron.org/media/avatars/NGYSRT_AAdAqMu.webp", "biography": "I've been contributing to GCC's C++ frontend since last year, and I worked on extending C++ support in GCC's static analyzer for GSoC 2026.\nI'm currently in the PhD preparatory phase at the Saarbr\u00fccken Grad School of Computer Science, and I am a Comp. Sci. and Eng. graduate from IST Lisbon.", "public_name": "Egas Ribeiro", "guid": "b9bf3b16-d814-53fb-aef5-33caff8be808", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/EJ3DN3/"}], "links": [{"title": "Slides for the talk", "url": "https://riogu.github.io/posts/cauldron-presentation-2026", "type": "related"}], "feedback_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/CNN8WR/feedback/", "origin_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/CNN8WR/", "attachments": []}, {"guid": "3d0bb9f3-4038-548a-94ee-ab4d2601b2a8", "code": "ACPKEV", "id": 105311, "logo": null, "date": "2026-10-02T12:00:00+02:00", "start": "12:00", "end": "2026-10-02T12:30:00+02:00", "duration": "00:30", "room": "Refectory (S 120)", "slug": "prg26-105311-compact-unwind-information-for-elf-platforms", "url": "https://conf.gnu-tools-cauldron.org/prg26/talk/ACPKEV/", "title": "Compact Unwind Information for ELF Platforms", "subtitle": "", "track": null, "type": "Talk (Short)", "language": "en", "abstract": "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.", "description": "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).\n\nIn 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.\n\nIn 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.", "recording_license": "", "do_not_record": false, "persons": [{"code": "UQ3SXP", "name": "Alexis Engelke", "avatar": null, "biography": "Alexis Engelke is a post-doctoral researcher in the Compiler Optimizations and Runtime Systems (Corse) group at Inria, primarily working on compiler back-ends and performance analysis tools.", "public_name": "Alexis Engelke", "guid": "b11d5e39-e497-5f5b-b2f8-b565aa19c121", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/UQ3SXP/"}], "links": [], "feedback_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/ACPKEV/feedback/", "origin_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/ACPKEV/", "attachments": []}, {"guid": "dcc14ecd-c4b3-56fb-a51d-4c8871d9ac6e", "code": "KDPJHR", "id": 105169, "logo": null, "date": "2026-10-02T13:30:00+02:00", "start": "13:30", "end": "2026-10-02T14:15:00+02:00", "duration": "00:45", "room": "Refectory (S 120)", "slug": "prg26-105169-gcc-rust-update", "url": "https://conf.gnu-tools-cauldron.org/prg26/talk/KDPJHR/", "title": "GCC Rust update", "subtitle": "", "track": null, "type": "Talk", "language": "en", "abstract": "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.\n\nThis 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.", "description": "", "recording_license": "", "do_not_record": false, "persons": [{"code": "B7SVMB", "name": "Pierre-Emmanuel Patry", "avatar": "https://conf.gnu-tools-cauldron.org/media/avatars/8CXX9D_RRUTQR5.webp", "biography": "GCC rust frontend maintainer, Pierre-Emmanuel has been involved with gccrs for the past four years.", "public_name": "Pierre-Emmanuel Patry", "guid": "18dc1833-1652-56d4-abfd-4d815d58bb39", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/B7SVMB/"}, {"code": "33BRUC", "name": "Enes Cevik", "avatar": "https://conf.gnu-tools-cauldron.org/media/avatars/U9LSSE_A9Zvd4K.webp", "biography": "Undergraduate CE student, working on gccrs (Rust for GCC)", "public_name": "Enes Cevik", "guid": "5c580c27-00b9-5db4-833a-7fa53316e2b0", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/33BRUC/"}, {"code": "XBHAGJ", "name": "Janet Chien", "avatar": null, "biography": "GCC Rust frontend and xDSL contributor", "public_name": "Janet Chien", "guid": "fdfe7859-bf8e-5add-b558-2aed807de0ef", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/XBHAGJ/"}], "links": [], "feedback_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/KDPJHR/feedback/", "origin_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/KDPJHR/", "attachments": []}, {"guid": "4e3348ae-0982-5e87-a9b1-6d4ae2b949ac", "code": "VB9NV7", "id": 104144, "logo": null, "date": "2026-10-02T14:15:00+02:00", "start": "14:15", "end": "2026-10-02T15:00:00+02:00", "duration": "00:45", "room": "Refectory (S 120)", "slug": "prg26-104144-a-gpu-centric-view-of-dwarf-6", "url": "https://conf.gnu-tools-cauldron.org/prg26/talk/VB9NV7/", "title": "A GPU-Centric View of DWARF 6", "subtitle": "", "track": null, "type": "Talk", "language": "en", "abstract": "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.\n\nIn particular\n - location and storage semantics have been clarified,\n - locations are now placed and processed in the evaluation stack along with values,\n - address space information can be expressed in locations and pointer types,\n - a new operator is proposed to build composite storages by overlaying a location on another location,\n - call frame information can express locations other than the default memory address space.\n\nThe talk can be useful for implementors of tools that produce or consume DWARF debug information.", "description": "", "recording_license": "", "do_not_record": false, "persons": [{"code": "NYXKTP", "name": "Baris Aktemur", "avatar": "https://conf.gnu-tools-cauldron.org/media/avatars/MFCHPT_gFT2END.webp", "biography": "Baris Aktemur works at AMD as a software engineer in the team that develops ROCgdb, the source-level debugger based on GDB for debugging programs running on AMD GPU devices. Baris is a contributor to GDB and a member of the DWARF committee.", "public_name": "Baris Aktemur", "guid": "23f9b4a2-e9f0-5668-8e41-a2c3bd3c2308", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/NYXKTP/"}], "links": [], "feedback_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/VB9NV7/feedback/", "origin_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/VB9NV7/", "attachments": []}, {"guid": "cdc7411e-3958-54ac-8b46-080496eea59f", "code": "K93GXZ", "id": 99333, "logo": null, "date": "2026-10-02T15:00:00+02:00", "start": "15:00", "end": "2026-10-02T15:30:00+02:00", "duration": "00:30", "room": "Refectory (S 120)", "slug": "prg26-99333-source-tracking-breakpoints-for-gdb", "url": "https://conf.gnu-tools-cauldron.org/prg26/talk/K93GXZ/", "title": "Source-Tracking Breakpoints for GDB", "subtitle": "", "track": null, "type": "Talk (Short)", "language": "en", "abstract": "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.\nThis 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.", "description": "I wrote an article about this feature: https://fedoramagazine.org/gdb-source-tracking-breakpoints/", "recording_license": "", "do_not_record": false, "persons": [{"code": "M8ZMDN", "name": "alexandra petlanova", "avatar": "https://conf.gnu-tools-cauldron.org/media/avatars/3JFBWN_9xWK97M.webp", "biography": "I'm Alexandra from the Czech Republic. I work in Red Hat. I'm interested in debugging, GDB, Valgrind and making them working well together.", "public_name": "alexandra petlanova", "guid": "4f3965b5-2941-5270-bf84-8efb031e72b1", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/M8ZMDN/"}], "links": [], "feedback_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/K93GXZ/feedback/", "origin_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/K93GXZ/", "attachments": []}, {"guid": "8bea66bc-9541-547e-a541-1494d498d597", "code": "A8QUJX", "id": 98270, "logo": null, "date": "2026-10-02T16:00:00+02:00", "start": "16:00", "end": "2026-10-02T17:00:00+02:00", "duration": "01:00", "room": "Refectory (S 120)", "slug": "prg26-98270-steering-committee-q-a", "url": "https://conf.gnu-tools-cauldron.org/prg26/talk/A8QUJX/", "title": "Steering Committee Q&A", "subtitle": "", "track": null, "type": "Talk", "language": "en", "abstract": "An opportunity for a GNU Toolchain community conversation with the members of the Steering Committees of the GNU Toolchain projects (GCC, GLIBC, Binutils, GDB).", "description": "", "recording_license": "", "do_not_record": false, "persons": [{"code": "ZLMMQW", "name": "David Edelsohn", "avatar": null, "biography": "Member of the GCC Steering Committee", "public_name": "David Edelsohn", "guid": "0dd20b93-b006-5439-a276-2d778d545055", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/ZLMMQW/"}], "links": [], "feedback_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/A8QUJX/feedback/", "origin_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/A8QUJX/", "attachments": []}], "Room S 9": [{"guid": "b51dbb62-ae93-5e6d-8dec-c450f7df012e", "code": "XAHX9K", "id": 105281, "logo": null, "date": "2026-10-02T14:00:00+02:00", "start": "14:00", "end": "2026-10-02T15:30:00+02:00", "duration": "01:30", "room": "Room S 9", "slug": "prg26-105281-practical-formalization-of-programming-language-semantics", "url": "https://conf.gnu-tools-cauldron.org/prg26/talk/XAHX9K/", "title": "Practical Formalization of Programming Language Semantics", "subtitle": "", "track": null, "type": "Tutorial", "language": "en", "abstract": "Ever since the introduction of the first high level programming\nlanguages it became necessary to develop techniques to precisely\ndescribe their structure (syntax), meaning (semantics) and the way\ntheir source constructs are to be used (pragmatics).\n\nThese specification techniques initially consisted almost entirely in\ncareful but inherently imprecise descriptions written in English or\nsome other natural language, but would quickly evolve to incorporate\nformal notations (or formalisms), the use of which would prove very\nbeneficial for language designers, implementors and users.\n\nIn 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.\n\nDue to limited time this talk is forced to be somewhat panoramic in\nnature, but printed handouts with additional material for further\nstudy will be distributed beforehand.\n\nPrevious knowledge on formal languages theory will undoubtly be\nadvantageous to the participant, but it is not absolutely necessary in\norder to follow and enjoy this talk.", "description": "", "recording_license": "", "do_not_record": false, "persons": [{"code": "9VT7SW", "name": "Jose Marchesi", "avatar": "https://conf.gnu-tools-cauldron.org/media/avatars/NQYMKF_d7jTr5G.webp", "biography": "GNU hacker and maintainer", "public_name": "Jose Marchesi", "guid": "82357286-b437-5022-b27e-e5e9c56c6f87", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/9VT7SW/"}], "links": [], "feedback_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/XAHX9K/feedback/", "origin_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/XAHX9K/", "attachments": []}], "Room S 5": [{"guid": "0e4563c5-154e-55a5-a014-7bd71c9720c5", "code": "YZQYFQ", "id": 105101, "logo": null, "date": "2026-10-02T14:00:00+02:00", "start": "14:00", "end": "2026-10-02T14:30:00+02:00", "duration": "00:30", "room": "Room S 5", "slug": "prg26-105101-the-sourceware-forge-experiment-year-2-and-onwards", "url": "https://conf.gnu-tools-cauldron.org/prg26/talk/YZQYFQ/", "title": "The Sourceware Forge Experiment - year 2 and onwards", "subtitle": "", "track": null, "type": "Talk (Short)", "language": "en", "abstract": "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", "description": "", "recording_license": "", "do_not_record": false, "persons": [{"code": "G9CRJ3", "name": "Richard Earnshaw", "avatar": null, "biography": "Richard Earnshaw has been working on various aspects of the GNU toolchain for over 30 years.  He's an Arm port maintainer for both GCC and binutils and in the past has dabbled in glibc and gdb as well.", "public_name": "Richard Earnshaw", "guid": "e166bc79-aee6-55c2-b947-2d969894ae2c", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/G9CRJ3/"}], "links": [], "feedback_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/YZQYFQ/feedback/", "origin_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/YZQYFQ/", "attachments": []}, {"guid": "a0a65edd-ee66-594e-9166-3c8fb4309fc3", "code": "MSU8HA", "id": 104226, "logo": null, "date": "2026-10-02T14:30:00+02:00", "start": "14:30", "end": "2026-10-02T15:00:00+02:00", "duration": "00:30", "room": "Room S 5", "slug": "prg26-104226-quantifying-register-pressure-16-bit-thumb-constraints-on-standard-optimization-passes", "url": "https://conf.gnu-tools-cauldron.org/prg26/talk/MSU8HA/", "title": "Quantifying Register Pressure: 16-Bit Thumb Constraints on Standard Optimization Passes", "subtitle": "", "track": null, "type": "Birds of a Feather (BoF)", "language": "en", "abstract": "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\u2013R7).\nWe 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.", "description": "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.", "recording_license": "", "do_not_record": false, "persons": [{"code": "NP9D8S", "name": "Visda Vokhshoori", "avatar": "https://conf.gnu-tools-cauldron.org/media/avatars/EW78HS_0DZqJRX.webp", "biography": "I have worked on IBM XL compiler's team targeting the Z series; then moved to Microchip XC32 Compiler's team targeting the 32-bit PIC and SAM Microcontrollers. \n I have gone from compiling for processors that take up a room to processors that fit on a fingernail.", "public_name": "Visda Vokhshoori", "guid": "029bef33-e25b-52cf-8907-bfb234ba4b54", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/NP9D8S/"}], "links": [], "feedback_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/MSU8HA/feedback/", "origin_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/MSU8HA/", "attachments": []}, {"guid": "c4dfba39-4197-55f0-9540-079ee11996cd", "code": "BFJEP7", "id": 105317, "logo": null, "date": "2026-10-02T15:00:00+02:00", "start": "15:00", "end": "2026-10-02T15:30:00+02:00", "duration": "00:30", "room": "Room S 5", "slug": "prg26-105317-reverse-engineering-cost-models-for-the-gcc-instruction-scheduler-a-case-study-on-the-bananapi-bpi-f3-risc-v-cpu", "url": "https://conf.gnu-tools-cauldron.org/prg26/talk/BFJEP7/", "title": "Reverse engineering cost models for the GCC instruction scheduler: a case study on the BananaPi BPI F3 RISC-V CPU", "subtitle": "", "track": null, "type": "Talk (Short)", "language": "en", "abstract": "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.\nThis talk covers topics which helped in deducing useful values for the scheduling model:\n* Micro-architectural benchmarks:\n    * Throughput analysis\n    * Gap analysis\n    * Latency analysis\n* Roofline analysis (cache aware)\n* Topdown Microarchitectural analysis - TDMA", "description": "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\u2019t 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.", "recording_license": "", "do_not_record": false, "persons": [{"code": "DHKGHL", "name": "Dusan Stojkovic", "avatar": null, "biography": "I'm a software engineer based in Novi Sad, Serbia with a passion for the RISC-V architecture, compilers and optimizing code. I have contributed to GCC in the past to improve the RISC-V software ecosystem and have published blog posts which go into detail on how to optimize code for HPC (AI, signal processing, big data etc.) using RISC-V Vector extension. Additionally, I'm a teaching assistant at the Faculty of Technical Sciences in Novi Sad where I hold labs for students about compilers, C and C++.", "public_name": "Dusan Stojkovic", "guid": "a640526f-f202-527a-b9ed-3a620ff98627", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/DHKGHL/"}], "links": [], "feedback_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/BFJEP7/feedback/", "origin_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/BFJEP7/", "attachments": []}]}}, {"index": 2, "date": "2026-10-03", "day_start": "2026-10-03T04:00:00+02:00", "day_end": "2026-10-04T03:59:00+02:00", "rooms": {"Room S 9": [{"guid": "1f95fcdd-9765-5a22-807b-3dc2efbd21ec", "code": "QJ8X9L", "id": 105235, "logo": null, "date": "2026-10-03T09:00:00+02:00", "start": "09:00", "end": "2026-10-03T09:30:00+02:00", "duration": "00:30", "room": "Room S 9", "slug": "prg26-105235-introducing-new-afdo-tools-for-autofdo-in-gcc", "url": "https://conf.gnu-tools-cauldron.org/prg26/talk/QJ8X9L/", "title": "Introducing new afdo-tools for AutoFDO in GCC", "subtitle": "", "track": null, "type": "Talk (Short)", "language": "en", "abstract": "AutoFDO is valued for its low-overhead profile collection that makes it ideal for frequent, large-scale deployment in CI/CD pipelines. However, GCC\u2019s 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\u2019s 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.\n\nThis 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.", "description": "", "recording_license": "", "do_not_record": false, "persons": [{"code": "KYBVRG", "name": "Kugan Vivekanandarajah", "avatar": null, "biography": "Kugan Vivekanandarajah is a CPU Compiler Engineer at NVIDIA. His work is primarily focused on implementing and enhancing optimizations for the AArch64 architecture.", "public_name": "Kugan Vivekanandarajah", "guid": "d6a902fb-1445-52ff-b8d9-425cca1ad014", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/KYBVRG/"}], "links": [], "feedback_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/QJ8X9L/feedback/", "origin_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/QJ8X9L/", "attachments": []}, {"guid": "00e0be66-3325-50f5-87e4-49642cbf98eb", "code": "YVMRNE", "id": 104900, "logo": null, "date": "2026-10-03T09:30:00+02:00", "start": "09:30", "end": "2026-10-03T10:00:00+02:00", "duration": "00:30", "room": "Room S 9", "slug": "prg26-104900-improving-autofdo-with-perf-gcov", "url": "https://conf.gnu-tools-cauldron.org/prg26/talk/YVMRNE/", "title": "Improving autofdo with perf-gcov", "subtitle": "", "track": null, "type": "Talk (Short)", "language": "en", "abstract": "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.", "description": "", "recording_license": "", "do_not_record": false, "persons": [{"code": "VBKLZ7", "name": "Andi Kleen", "avatar": null, "biography": "Andi Kleen is a long time lurker and occasional contributor to gcc.  He's interested in improving performance in many ways.", "public_name": "Andi Kleen", "guid": "c729dc2a-47aa-566b-a85f-df321397ff3a", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/VBKLZ7/"}], "links": [], "feedback_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/YVMRNE/feedback/", "origin_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/YVMRNE/", "attachments": [{"title": "Slides", "url": "/media/prg26/submissions/YVMRNE/resources/perf-gcov_ML5Zman.pdf", "type": "related"}]}, {"guid": "bec0eacf-fdaa-524e-a683-0c5b7545af2f", "code": "BM3WHC", "id": 100449, "logo": null, "date": "2026-10-03T10:30:00+02:00", "start": "10:30", "end": "2026-10-03T11:30:00+02:00", "duration": "01:00", "room": "Room S 9", "slug": "prg26-100449-configury-build-system-bof", "url": "https://conf.gnu-tools-cauldron.org/prg26/talk/BM3WHC/", "title": "Configury/Build System BoF", "subtitle": "", "track": null, "type": "Birds of a Feather (BoF)", "language": "en", "abstract": "Configury/Build System BoF\n\nThe 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:\n\n* Current pain points\n  What makes configure slow, hard to debug, or difficult to extend?\n\n* Upgrades\n  Should we upgrade Autotools? To which versions? What breaks? What do we gain?\n\n* Duplication and necessary cleanups\n  Which patterns are shared across components or trees? What has become redundant due to upgrades?\n\n* Shared governance\n  Keeping GCC, Binutils, and GDB in sync. For example, the \"config\" directory is not identical on both trees. Could we automate synchronization?\n\n* Next steps\n  Which improvements are quick wins? What belongs on a long-term roadmap?\n\n* Explore longer-term possibilities\n  What would fundamentally improve our build system?", "description": "", "recording_license": "", "do_not_record": false, "persons": [{"code": "WZ87AU", "name": "pietro", "avatar": null, "biography": "I've been hacking on the GCC Algol 68 frontend.", "public_name": "pietro", "guid": "37c5cd28-c1cc-57da-99fc-b377433e7957", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/WZ87AU/"}], "links": [], "feedback_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/BM3WHC/feedback/", "origin_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/BM3WHC/", "attachments": []}, {"guid": "585a0020-ae2f-5010-aea7-ecd4e028460b", "code": "HS9RPC", "id": 105312, "logo": null, "date": "2026-10-03T11:30:00+02:00", "start": "11:30", "end": "2026-10-03T12:00:00+02:00", "duration": "00:30", "room": "Room S 9", "slug": "prg26-105312-smart-alignment-reducing-code-size-on-x86-without-performance-impact", "url": "https://conf.gnu-tools-cauldron.org/prg26/talk/HS9RPC/", "title": "Smart Alignment - Reducing Code Size on x86 without Performance Impact", "subtitle": "", "track": null, "type": "Talk (Short)", "language": "en", "abstract": "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.\n\nSmart 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.\n\nPerformance 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.", "description": "", "recording_license": "", "do_not_record": false, "persons": [{"code": "UQLCD7", "name": "Sarvesh Chandra", "avatar": "https://conf.gnu-tools-cauldron.org/media/avatars/GMTSDW_HvFmHp6.webp", "biography": "I am a junior compiler engineer at AMD passionate about compilers and computer architecture. I work primarily on GCC x86 backend.", "public_name": "Sarvesh Chandra", "guid": "7911c4c4-3530-5600-b826-7ce53224e8c3", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/UQLCD7/"}, {"code": "JASWCA", "name": "Venkataramanan Kumar", "avatar": "https://conf.gnu-tools-cauldron.org/media/avatars/VXHSAF_Ul2Gnyq.webp", "biography": "Principal member of technical staff at AMD.  Working in GCC and AOCC compilers.", "public_name": "Venkataramanan Kumar", "guid": "9c5ec66e-2d2a-5a27-99db-12903582cf55", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/JASWCA/"}, {"code": "WG7H8J", "name": "Branden Moore", "avatar": null, "biography": "AMD Fellow, CPU Performance Analysis and Compilers.", "public_name": "Branden Moore", "guid": "9774e4c8-8a9c-541a-b34b-0b6748c12183", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/WG7H8J/"}], "links": [{"title": "GCC Patch", "url": "https://gcc.gnu.org/pipermail/gcc-patches/2026-October/733349.html", "type": "related"}, {"title": "Binutils Patch", "url": "https://sourceware.org/pipermail/binutils/2026-October/151827.html", "type": "related"}], "feedback_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/HS9RPC/feedback/", "origin_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/HS9RPC/", "attachments": [{"title": "Slides", "url": "/media/prg26/submissions/HS9RPC/resources/smart-alignment-cau_FCun61z.pptx", "type": "related"}]}, {"guid": "e164fb20-47fe-5172-91be-43bfa6c7e4c1", "code": "S8AGLY", "id": 104865, "logo": null, "date": "2026-10-03T12:00:00+02:00", "start": "12:00", "end": "2026-10-03T12:15:00+02:00", "duration": "00:15", "room": "Room S 9", "slug": "prg26-104865-debugging-of-c-c-macros-like-functions", "url": "https://conf.gnu-tools-cauldron.org/prg26/talk/S8AGLY/", "title": "Debugging of C/C++ Macros like Functions", "subtitle": "", "track": null, "type": "Lightning Talks", "language": "en", "abstract": "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.\n\nThe 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.\n\nTo 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.", "description": "Additionally, I will present a demo of the developed [plugin](https://github.com/cast-tech/GDB-Macro-Debugger).", "recording_license": "", "do_not_record": false, "persons": [{"code": "SPJ7GL", "name": "Hayk Aslanyan", "avatar": "https://conf.gnu-tools-cauldron.org/media/avatars/BLQM7B_rkMfLB8.webp", "biography": "I am a researcher, lecturer, and software engineer specializing in compiler technologies, program static and dynamic analysis, and software security. I received my PhD in 2019.\nI lead an R&D team at the Center of Advanced Software Technologies (CAST), where our work focuses on compiler optimization, automated program analysis, vulnerability detection, binary code analysis, and machine-learning-based software optimization. Our team has developed and evaluated analysis tools for detecting software vulnerabilities and conducted research involving real-world open-source projects, CVEs, and established benchmark suites.\nIn addition to my research activities, I am actively involved in education, where I develop practical programming courses, automated assessment systems, and research-oriented internship programs.", "public_name": "Hayk Aslanyan", "guid": "f46b1386-5910-5743-a7ff-83bc2224db9f", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/SPJ7GL/"}], "links": [{"title": "Code", "url": "https://github.com/cast-tech/GDB-Macro-Debugger", "type": "related"}], "feedback_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/S8AGLY/feedback/", "origin_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/S8AGLY/", "attachments": [{"title": "Debugging macros like functions", "url": "/media/prg26/submissions/S8AGLY/resources/debugging_macros_lik_aS6CEqu.pdf", "type": "related"}]}, {"guid": "d7b6518e-4141-5e82-ba26-53c5447f2641", "code": "BXDCZA", "id": 105301, "logo": null, "date": "2026-10-03T12:15:00+02:00", "start": "12:15", "end": "2026-10-03T12:30:00+02:00", "duration": "00:15", "room": "Room S 9", "slug": "prg26-105301-beyond-branches-arm-pmu-spe-as-a-memory-side-profile-source-for-gcc-autofdo", "url": "https://conf.gnu-tools-cauldron.org/prg26/talk/BXDCZA/", "title": "Beyond Branches: Arm PMU/SPE as a Memory-Side Profile Source for GCC AutoFDO", "subtitle": "", "track": null, "type": "Lightning Talks", "language": "en", "abstract": "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 \u2014 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 \u2014 data layout, prefetch distance, load speculation \u2014 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.\n\nWe 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 \u2014 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.\n\nWhat 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.", "description": "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.\n\nIn 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.", "recording_license": "", "do_not_record": false, "persons": [{"code": "3BNGE3", "name": "huangxiaoquan", "avatar": "https://conf.gnu-tools-cauldron.org/media/avatars/SMHU3Q_lKWWRuD.webp", "biography": "Compiler engineer on the openEuler toolchain team, maintaining the AArch64 side of the distribution's GCC across its release lines. One of the authors of the tuning model for HiSilicon's Kunpeng server cores, most recently hip12, and currently working on memory-side profile feedback for AArch64 \u2014 teaching AutoFDO to consume more than branches. This is our team's first Cauldron.", "public_name": "huangxiaoquan", "guid": "57691ed6-6cac-5f6d-92d1-083703dc8266", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/3BNGE3/"}], "links": [], "feedback_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/BXDCZA/feedback/", "origin_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/BXDCZA/", "attachments": [{"title": "Beyond Branches: Arm PMU SPE as a Memory-Side Profile Source for GCC AutoFDO.pptx", "url": "/media/prg26/submissions/BXDCZA/resources/Beyond-Branches-SPE_9oFdtGF.pptx", "type": "related"}]}, {"guid": "968a511b-7a2d-5a0e-8723-2ff6ebd5c647", "code": "Y83C3C", "id": 105368, "logo": null, "date": "2026-10-03T13:30:00+02:00", "start": "13:30", "end": "2026-10-03T14:30:00+02:00", "duration": "01:00", "room": "Room S 9", "slug": "prg26-105368-gdb-on-windows-status-plans-2026-edition", "url": "https://conf.gnu-tools-cauldron.org/prg26/talk/Y83C3C/", "title": "GDB on Windows: status & plans (2026 edition)", "subtitle": "", "track": null, "type": "Talk", "language": "en", "abstract": "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.\n\nIn 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.\n\n- Teaching GDB about {x86_64,aarch64,i386}-pc-windows-msvc targets\n  - Windows-MSVC vs Windows-GNU GDB ABI split\n  - Windows/MSVC calling conventions\n  - Catching C++ exceptions\n  - Microsoft's C++ name mangling (aka name decoration) scheme\n    (instead of Itanium mangling scheme supported by libiberty)\n  - Vtable & object layout (not Itanium)\n- Teaching GDB about PDB (Portable Database), Microsoft's debug info format (not DWARF)\n- Teaching testsuite about {x86_64,aarch64,i386}-pc-windows-msvc targets\n  - Different linker (lld-link or MSFT's link.exe)\n  - Visual C++ headers & libraries, not MinGW\n  - PDB by default\n- More", "description": "", "recording_license": "", "do_not_record": false, "persons": [{"code": "UNWB8D", "name": "Pedro Alves", "avatar": null, "biography": "I've been contributing to GDB for close to two decades.  In the last few years I've been spending most of my time working with AMD on ROCgdb, the AMD GPU debugger based on GDB.", "public_name": "Pedro Alves", "guid": "008f5aa3-e242-521b-bcf1-e86e73ab1e27", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/UNWB8D/"}], "links": [], "feedback_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/Y83C3C/feedback/", "origin_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/Y83C3C/", "attachments": []}, {"guid": "680c4c94-c9d0-56bc-8e66-9161bd46320e", "code": "PWJ87E", "id": 105373, "logo": null, "date": "2026-10-03T14:30:00+02:00", "start": "14:30", "end": "2026-10-03T15:30:00+02:00", "duration": "01:00", "room": "Room S 9", "slug": "prg26-105373-data-type-profiling-pairing-perf-with-pahole", "url": "https://conf.gnu-tools-cauldron.org/prg26/talk/PWJ87E/", "title": "Data-type profiling: pairing perf with pahole", "subtitle": "", "track": null, "type": "Talk", "language": "en", "abstract": "Today we have two complementary, disconnected views of a struct:\n\n- 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.\n\n- 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.\n\nThis 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.", "description": "", "recording_license": "", "do_not_record": false, "persons": [{"code": "DGVLEP", "name": "Arnaldo Carvalho de Melo", "avatar": null, "biography": "Linux perf tools maintainer, pahole for your data structures & function details, Red Hat.", "public_name": "Arnaldo Carvalho de Melo", "guid": "628d1cef-af14-524d-b5cc-e49f14f4b2fa", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/DGVLEP/"}], "links": [], "feedback_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/PWJ87E/feedback/", "origin_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/PWJ87E/", "attachments": []}, {"guid": "f1ef7a5a-e5f7-5ec5-8ba2-6ca3b52a4268", "code": "RDQK7U", "id": 105366, "logo": null, "date": "2026-10-03T16:00:00+02:00", "start": "16:00", "end": "2026-10-03T17:00:00+02:00", "duration": "01:00", "room": "Room S 9", "slug": "prg26-105366-the-gdb-bof", "url": "https://conf.gnu-tools-cauldron.org/prg26/talk/RDQK7U/", "title": "The GDB BoF", "subtitle": "", "track": null, "type": "Birds of a Feather (BoF)", "language": "en", "abstract": "An opportunity for the GDB community to meet to discuss all things related to the GNU Debugger project.", "description": "", "recording_license": "", "do_not_record": false, "persons": [{"code": "UNWB8D", "name": "Pedro Alves", "avatar": null, "biography": "I've been contributing to GDB for close to two decades.  In the last few years I've been spending most of my time working with AMD on ROCgdb, the AMD GPU debugger based on GDB.", "public_name": "Pedro Alves", "guid": "008f5aa3-e242-521b-bcf1-e86e73ab1e27", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/UNWB8D/"}], "links": [], "feedback_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/RDQK7U/feedback/", "origin_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/RDQK7U/", "attachments": []}], "Room S 5": [{"guid": "adff09a8-f846-5efe-9250-58c43a2d8186", "code": "3HRHA9", "id": 105405, "logo": null, "date": "2026-10-03T09:00:00+02:00", "start": "09:00", "end": "2026-10-03T09:45:00+02:00", "duration": "00:45", "room": "Room S 5", "slug": "prg26-105405-register-allocator-and-shrink-wrapping", "url": "https://conf.gnu-tools-cauldron.org/prg26/talk/3HRHA9/", "title": "Register Allocator and Shrink Wrapping", "subtitle": "", "track": null, "type": "Talk", "language": "en", "abstract": "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.\n\nHowever, 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.\n\nThis 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:\n\n- A missing cost term in IRA's post-coloring refinement pass (_improve_allocation_) \u2014 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.\n\n- A frequency-scaling omission in IRA's primary assignment function (_assign_hard_reg_) \u2014 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.\n\n   - Fixing this issue resulted in performance improvements in SPEC 2017 (**4%** in perlbench and **2.6%** in povray) on Power10 processor.\n\n- Eager spill placement in LRA's inheritance/splitting pass (_inherit_in_ebb_) \u2014 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 \u2014 which references the stack pointer \u2014 lands in the entry block. This prevents shrink wrapping.\n\nThe talk will discuss the root causes, the fixes and the interaction between register allocation and shrink wrap optimization.", "description": "", "recording_license": "", "do_not_record": false, "persons": [{"code": "EMPDWU", "name": "Surya Kumari J", "avatar": null, "biography": "Surya Kumari J works on the Powerpc port of the GCC compiler and currently serves as the GCC Powerpc port reviewer. Over a 24-year career, she has worked on compilers (both static and JIT) and toolchains for a variety of processors, including PA-RISC, Itanium and Power.", "public_name": "Surya Kumari J", "guid": "3034734c-9b33-5463-b49e-c631f029449f", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/EMPDWU/"}], "links": [], "feedback_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/3HRHA9/feedback/", "origin_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/3HRHA9/", "attachments": []}, {"guid": "9fae704e-fb43-5e24-9e17-739877f66380", "code": "ARPWWW", "id": 105300, "logo": null, "date": "2026-10-03T09:45:00+02:00", "start": "09:45", "end": "2026-10-03T10:00:00+02:00", "duration": "00:15", "room": "Room S 5", "slug": "prg26-105300-helping-released-gccs-support-new-cpus-from-field-problems-to-a-cross-version-interface-proposal", "url": "https://conf.gnu-tools-cauldron.org/prg26/talk/ARPWWW/", "title": "Helping Released GCCs Support New CPUs: From Field Problems to a Cross-Version Interface Proposal", "subtitle": "", "track": null, "type": "Lightning Talks", "language": "en", "abstract": "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.\n\nThe 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.\n\nTwo 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\u2014target policy, vector-cost heuristics and vector-width estimates\u2014to 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.\n\nThese 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.", "description": "", "recording_license": "", "do_not_record": false, "persons": [{"code": "3BNGE3", "name": "huangxiaoquan", "avatar": "https://conf.gnu-tools-cauldron.org/media/avatars/SMHU3Q_lKWWRuD.webp", "biography": "Compiler engineer on the openEuler toolchain team, maintaining the AArch64 side of the distribution's GCC across its release lines. One of the authors of the tuning model for HiSilicon's Kunpeng server cores, most recently hip12, and currently working on memory-side profile feedback for AArch64 \u2014 teaching AutoFDO to consume more than branches. This is our team's first Cauldron.", "public_name": "huangxiaoquan", "guid": "57691ed6-6cac-5f6d-92d1-083703dc8266", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/3BNGE3/"}], "links": [], "feedback_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/ARPWWW/feedback/", "origin_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/ARPWWW/", "attachments": [{"title": "Helping Released GCCs Support New CPUs slides", "url": "/media/prg26/submissions/ARPWWW/resources/cauldron-2026-p1-v7_AzzTM61.pptx", "type": "related"}]}, {"guid": "7559d3ab-b152-519d-ad13-cea405999c68", "code": "L9WJP7", "id": 104810, "logo": null, "date": "2026-10-03T10:30:00+02:00", "start": "10:30", "end": "2026-10-03T11:00:00+02:00", "duration": "00:30", "room": "Room S 5", "slug": "prg26-104810-manual-vectorization-for-gnu-fortran", "url": "https://conf.gnu-tools-cauldron.org/prg26/talk/L9WJP7/", "title": "Manual vectorization for GNU Fortran", "subtitle": "", "track": null, "type": "Talk (Short)", "language": "en", "abstract": "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.\n\nThis 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.", "description": "", "recording_license": "", "do_not_record": false, "persons": [{"code": "FJUXVK", "name": "Magnus Weinm\u00fcller", "avatar": null, "biography": "M.Sc. student in informatics at Technical University Munich, Germany", "public_name": "Magnus Weinm\u00fcller", "guid": "922bef90-95d4-5501-a936-ba731eaa4ebe", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/FJUXVK/"}, {"code": "MGW8QN", "name": "Henri Menke", "avatar": null, "biography": null, "public_name": "Henri Menke", "guid": "d7ca0cac-5403-543b-8e3a-c6dcfa7ecb12", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/MGW8QN/"}], "links": [], "feedback_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/L9WJP7/feedback/", "origin_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/L9WJP7/", "attachments": []}, {"guid": "2029c63d-4da9-599e-9b9e-7f61633f6b39", "code": "C3PSEQ", "id": 103791, "logo": null, "date": "2026-10-03T11:00:00+02:00", "start": "11:00", "end": "2026-10-03T12:00:00+02:00", "duration": "01:00", "room": "Room S 5", "slug": "prg26-103791-offloading-openmp-and-openacc-in-gcc", "url": "https://conf.gnu-tools-cauldron.org/prg26/talk/C3PSEQ/", "title": "Offloading, OpenMP, and OpenACC in GCC", "subtitle": "", "track": null, "type": "Talk", "language": "en", "abstract": "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.", "description": "", "recording_license": "", "do_not_record": false, "persons": [{"code": "ENWEFY", "name": "Tobias Burnus", "avatar": null, "biography": "Tobias Burnus is a Senior Software Engineer at [BayLibre](https://baylibre.com/)'s compiler-service team. His current focus is on the compiler support for OpenMP, OpenACC and GPU offloading for C, C++ and Fortran. He obtained an M.Sc. in Physics in 2004 from Free University Berlin and received 2008 a doctorate in the natural sciences (Dr. rer. nat.) from the University of Cologne; his research involved quantum-mechanical numerical calculations (DFT, CI) on molecules and solids. Tobias contributes since 2006 to the GNU Compiler Collection, initially mainly to its Fortran compiler. His interests include parallel computing, numerical calculations, parallel programming and heterogeneous programming. Tobias is a GCC maintainer for Fortran, OpenMP and OpenACC and contributes to the respective specifications.", "public_name": "Tobias Burnus", "guid": "efbb5717-3c5e-5b85-9329-d7481a35503c", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/ENWEFY/"}, {"code": "VRELN7", "name": "Thomas Schwinge", "avatar": "https://conf.gnu-tools-cauldron.org/media/avatars/BX89LB_zvr0heA.webp", "biography": "Software engineer, primarily working on [GCC (GNU Compiler Collection)](https://gcc.gnu.org/), in particular adding support for [OpenACC](https://gcc.gnu.org/wiki/OpenACC)/[OpenMP](https://gcc.gnu.org/wiki/OpenMP) (directive-based parallel programming models) with [code offloading](https://gcc.gnu.org/wiki/Offloading) to Nvidia GPUs (project started in 2013-06), and AMD GPUs.  In 2018-09, appointed GCC/OpenACC maintainer, in 2023-07 appointed GCC/nvptx maintainer.  Active member of the [OpenACC Technical Committee](https://openacc.org/).\n\nPart of the team developing [GCC/Rust](https://rust-gcc.github.io/): a GCC front end for the Rust programming language.\n\nI also worked on glibc, GDB, binutils, etc., and had a brief look into the world of LLVM, but GCC etc. is still keeping me busy.\n\nEmployed by [BayLibre](https://baylibre.com/).\n\nBackground in electrical engineering, focus on computer engineering, graduating from the Universit\u00e4t Stuttgart with a Diplom-Ingenieur (Dipl.-Ing., compare to M.Eng.) degree.\n\n  * <https://fosstodon.org/@tschwinge>\n  * <https://bsky.app/profile/tschwinge.bsky.social>\n  * <https://twitter.com/schwinge_thomas>\n  * <https://www.linkedin.com/in/tschwinge>\n  * <https://github.com/tschwinge/>", "public_name": "Thomas Schwinge", "guid": "417937df-487e-514d-90a9-420f86d2db50", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/VRELN7/"}], "links": [], "feedback_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/C3PSEQ/feedback/", "origin_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/C3PSEQ/", "attachments": [{"title": "Slides for Offloading, OpenMP, and OpenACC in GCC", "url": "/media/prg26/submissions/C3PSEQ/resources/Cauldron_2026__Offlo_8JM7i0Z.pdf", "type": "related"}]}, {"guid": "107b8d32-676b-563b-9619-05f193175ef8", "code": "CDZHQJ", "id": 104150, "logo": null, "date": "2026-10-03T12:00:00+02:00", "start": "12:00", "end": "2026-10-03T12:30:00+02:00", "duration": "00:30", "room": "Room S 5", "slug": "prg26-104150-libgompt-enabling-ompt-for-libgomp", "url": "https://conf.gnu-tools-cauldron.org/prg26/talk/CDZHQJ/", "title": "libgOMPT: Enabling OMPT for libgomp", "subtitle": "", "track": null, "type": "Talk (Short)", "language": "en", "abstract": "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.\n\nThis 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.\n\nBeyond 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.", "description": "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.\nWe 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.\nThis talk should be interesting for anyone working on OpenMP runtimes, GCC/libgomp, performance tools, or the future of tooling support in the GNU ecosystem.", "recording_license": "", "do_not_record": false, "persons": [{"code": "BTGJ7C", "name": "Jan Kraus", "avatar": null, "biography": "PhD candidate at Chair for High-Performance Computing @ RWTH Aachen University. Research includes parallel runtime analysis and performance tools for HPC applications.\n\nhttps://orcid.org/0009-0003-1961-6905", "public_name": "Jan Kraus", "guid": "8d1892ce-7fe6-5414-9e03-a44762b26539", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/BTGJ7C/"}, {"code": "VRELN7", "name": "Thomas Schwinge", "avatar": "https://conf.gnu-tools-cauldron.org/media/avatars/BX89LB_zvr0heA.webp", "biography": "Software engineer, primarily working on [GCC (GNU Compiler Collection)](https://gcc.gnu.org/), in particular adding support for [OpenACC](https://gcc.gnu.org/wiki/OpenACC)/[OpenMP](https://gcc.gnu.org/wiki/OpenMP) (directive-based parallel programming models) with [code offloading](https://gcc.gnu.org/wiki/Offloading) to Nvidia GPUs (project started in 2013-06), and AMD GPUs.  In 2018-09, appointed GCC/OpenACC maintainer, in 2023-07 appointed GCC/nvptx maintainer.  Active member of the [OpenACC Technical Committee](https://openacc.org/).\n\nPart of the team developing [GCC/Rust](https://rust-gcc.github.io/): a GCC front end for the Rust programming language.\n\nI also worked on glibc, GDB, binutils, etc., and had a brief look into the world of LLVM, but GCC etc. is still keeping me busy.\n\nEmployed by [BayLibre](https://baylibre.com/).\n\nBackground in electrical engineering, focus on computer engineering, graduating from the Universit\u00e4t Stuttgart with a Diplom-Ingenieur (Dipl.-Ing., compare to M.Eng.) degree.\n\n  * <https://fosstodon.org/@tschwinge>\n  * <https://bsky.app/profile/tschwinge.bsky.social>\n  * <https://twitter.com/schwinge_thomas>\n  * <https://www.linkedin.com/in/tschwinge>\n  * <https://github.com/tschwinge/>", "public_name": "Thomas Schwinge", "guid": "417937df-487e-514d-90a9-420f86d2db50", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/VRELN7/"}], "links": [], "feedback_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/CDZHQJ/feedback/", "origin_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/CDZHQJ/", "attachments": [{"title": "Presentation Slides", "url": "/media/prg26/submissions/CDZHQJ/resources/2026-10-08_libGOMPT_DN2IMyx.pdf", "type": "related"}]}, {"guid": "6b25f1d2-6e38-5448-8f15-d8d78705e4d6", "code": "TXRXTF", "id": 105777, "logo": null, "date": "2026-10-03T13:30:00+02:00", "start": "13:30", "end": "2026-10-03T14:00:00+02:00", "duration": "00:30", "room": "Room S 5", "slug": "prg26-105777-enabling-glibc-shadow-stack-runtime-in-fedora", "url": "https://conf.gnu-tools-cauldron.org/prg26/talk/TXRXTF/", "title": "Enabling glibc Shadow Stack Runtime in Fedora", "subtitle": "", "track": null, "type": "Talk (Short)", "language": "en", "abstract": "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.", "description": "", "recording_license": "", "do_not_record": false, "persons": [{"code": "DRXXXS", "name": "Arjun Shankar", "avatar": "https://conf.gnu-tools-cauldron.org/media/avatars/7HTTZA_j9ZvQyj.webp", "biography": "I'm a glibc developer based in Brno and working for Red Hat.", "public_name": "Arjun Shankar", "guid": "9a4c098f-f49e-5617-abb6-a53c64bb80b9", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/DRXXXS/"}], "links": [], "feedback_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/TXRXTF/feedback/", "origin_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/TXRXTF/", "attachments": []}, {"guid": "9df21b78-2afa-5fc2-a982-c9013a001e71", "code": "9S88YF", "id": 104687, "logo": null, "date": "2026-10-03T14:00:00+02:00", "start": "14:00", "end": "2026-10-03T15:00:00+02:00", "duration": "01:00", "room": "Room S 5", "slug": "prg26-104687-bof-on-gcc-and-ai", "url": "https://conf.gnu-tools-cauldron.org/prg26/talk/9S88YF/", "title": "BoF on GCC and AI", "subtitle": "", "track": null, "type": "Birds of a Feather (BoF)", "language": "en", "abstract": "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.", "description": "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:\n- What's changed since last year: new accelerator targets, upstream activity etc.\n- Experiences building GCC/toolchain support for custom NPU and vector extensions: what's reusable versus target-specific.\n- Where is external tooling (runtime-level) a better fit?", "recording_license": "", "do_not_record": false, "persons": [{"code": "C8B9QC", "name": "Pietra Ferreira", "avatar": "https://conf.gnu-tools-cauldron.org/media/avatars/3BZG8T_Tu3qdnN.webp", "biography": "Pietra Ferreira is a member of Embecosm\u2019s tool chain engineering team. They are well known for their contribution to the development of the Open Hardware Group\u2019s GCC compiler tool chain. Their latest work focus on porting Meta's ExecuTorch edge inference runtime to bare-metal multi-core RISC-V microcontrollers, including custom NPU backends, partitioners, quantisers, and optimised kernels.", "public_name": "Pietra Ferreira", "guid": "72330643-62b2-56d3-9a03-34e014e271f0", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/C8B9QC/"}], "links": [], "feedback_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/9S88YF/feedback/", "origin_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/9S88YF/", "attachments": []}, {"guid": "3a0c06a3-ad57-570e-8bfd-184074b4ba6e", "code": "YF3MFA", "id": 102297, "logo": null, "date": "2026-10-03T15:00:00+02:00", "start": "15:00", "end": "2026-10-03T15:30:00+02:00", "duration": "00:30", "room": "Room S 5", "slug": "prg26-102297-bpf-bof", "url": "https://conf.gnu-tools-cauldron.org/prg26/talk/YF3MFA/", "title": "BPF BoF", "subtitle": "", "track": null, "type": "Birds of a Feather (BoF)", "language": "en", "abstract": "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.", "description": "", "recording_license": "", "do_not_record": false, "persons": [{"code": "T8GG3Y", "name": "David Faust", "avatar": null, "biography": "BPF target support in GCC and binutils.  Reviewer for CTF and BTF generation in GCC.  GNU poke enthusiast.  Recently started working with the AArch64 backend and optimization.", "public_name": "David Faust", "guid": "c1892918-7c1c-5365-8501-ced001da663b", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/T8GG3Y/"}, {"code": "VYTQZE", "name": "Vineet Gupta", "avatar": "https://conf.gnu-tools-cauldron.org/media/avatars/KVSKDM_g7X6y63.webp", "biography": "I work on gcc BPF backend at Meta and before that I was hacking on the RISC-V gcc backend. I'm a seasoned Open Source Hacker still proud of my first public contribution to Busybox and over a career of 25 years I've ported, upstreamed and maintained Linux kernel, glibc and several other projects to multiple generation and ISA of Synopsys ARC processors. I'm really passionate about making gcc more accessible for new developers.", "public_name": "Vineet Gupta", "guid": "e7842725-710d-5a81-a855-e577316ee5aa", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/VYTQZE/"}, {"code": "9VT7SW", "name": "Jose Marchesi", "avatar": "https://conf.gnu-tools-cauldron.org/media/avatars/NQYMKF_d7jTr5G.webp", "biography": "GNU hacker and maintainer", "public_name": "Jose Marchesi", "guid": "82357286-b437-5022-b27e-e5e9c56c6f87", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/9VT7SW/"}], "links": [], "feedback_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/YF3MFA/feedback/", "origin_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/YF3MFA/", "attachments": []}, {"guid": "3e8349a5-0adf-5177-a780-e54321d01aa4", "code": "7R9YLV", "id": 96480, "logo": null, "date": "2026-10-03T16:00:00+02:00", "start": "16:00", "end": "2026-10-03T17:00:00+02:00", "duration": "01:00", "room": "Room S 5", "slug": "prg26-96480-what-s-new-with-diagnostics-in-gcc-17", "url": "https://conf.gnu-tools-cauldron.org/prg26/talk/7R9YLV/", "title": "What's new with diagnostics in GCC 17", "subtitle": "", "track": null, "type": "Talk", "language": "en", "abstract": "This talk will cover:\n\n- a prototype implementation of an [LSP server]([url](https://langserver.org/)) using GCC's frontends\n- improvements to GCC's `-fanalyzer` option\n- improvements to GCC's diagnostics subsystem", "description": "", "recording_license": "", "do_not_record": false, "persons": [{"code": "CL7ATE", "name": "David Malcolm", "avatar": null, "biography": "I work at Red Hat on GCC, focusing on diagnostics, user experience, and static analysis.", "public_name": "David Malcolm", "guid": "0ef2e265-38b6-5216-9e68-0583bb5151b1", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/CL7ATE/"}], "links": [], "feedback_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/7R9YLV/feedback/", "origin_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/7R9YLV/", "attachments": [{"title": "Slides for \u201cWhat's new with diagnostics in GCC 17\u201d", "url": "/media/prg26/submissions/7R9YLV/resources/2026-Cauldron-diagno_9Tlq5KE.pdf", "type": "related"}]}], "Room S (Floor 3)": [{"guid": "25cd049f-3fbf-5b16-8bd1-931d7e5445df", "code": "TZERQV", "id": 95813, "logo": null, "date": "2026-10-03T09:00:00+02:00", "start": "09:00", "end": "2026-10-03T10:00:00+02:00", "duration": "01:00", "room": "Room S (Floor 3)", "slug": "prg26-95813-gnu-c-library-bof", "url": "https://conf.gnu-tools-cauldron.org/prg26/talk/TZERQV/", "title": "GNU C Library BoF", "subtitle": "", "track": null, "type": "Birds of a Feather (BoF)", "language": "en", "abstract": "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.", "description": "This BoF aims to bring together developers of other components that have dependencies on glibc and glibc developers to talk about the following topics:\n\n* Planning for Core Toolchain Infrastructure transition and open questions.\n\n* Planning for glibc 2.45 and what work needs to be done between September 2026 and February 2027.\n\n* Planning for glibc 2.46 and what work needs to be done between February 2027 and August 2027.\n\n... and more.", "recording_license": "", "do_not_record": false, "persons": [{"code": "AJ3FMZ", "name": "Carlos O'Donell", "avatar": "https://conf.gnu-tools-cauldron.org/media/avatars/XJPLRH_ZJDiL4H.webp", "biography": "Upstream glibc developer with 20+ years of project experience.\n\nOne of 8 GNU Project package maintainers for glibc.\n\nDownstream distribution developer for Fedora, CentOS Stream and Red Hat Enterprise Linux.\n\nBringing a \"distribution\" perspective to upstream conversations.", "public_name": "Carlos O'Donell", "guid": "ebfff59c-9e64-5083-a2c4-596403479598", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/AJ3FMZ/"}, {"code": "MYVEN3", "name": "Adhemerval Zanella Netto", "avatar": "https://conf.gnu-tools-cauldron.org/media/avatars/7ANDKC_iHXBmtz.webp", "biography": "I work at Linaro.org as Toolchain Engineer, and I am a glibc maintainer.", "public_name": "Adhemerval Zanella Netto", "guid": "cfd6d6b4-e903-5bd5-8acb-1cfe7c3a9b46", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/MYVEN3/"}], "links": [], "feedback_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/TZERQV/feedback/", "origin_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/TZERQV/", "attachments": []}, {"guid": "eed032ad-f36c-556b-8ea7-6d5c3d3889d4", "code": "L7UHWJ", "id": 104209, "logo": null, "date": "2026-10-03T10:30:00+02:00", "start": "10:30", "end": "2026-10-03T11:30:00+02:00", "duration": "01:00", "room": "Room S (Floor 3)", "slug": "prg26-104209-x86-bof", "url": "https://conf.gnu-tools-cauldron.org/prg26/talk/L7UHWJ/", "title": "x86 BoF", "subtitle": "", "track": null, "type": "Birds of a Feather (BoF)", "language": "en", "abstract": "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.", "description": "Discussions are warmly welcomed in the BoF.\nHere is what we will prepare in advance for background:\nFor APX part, we will have a \"brief\" introduction for all the features.\nFor ACE part, we will mainly focus on the current implementation in GCC17, and our implementation difference with LLVM.\nFor 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.", "recording_license": "", "do_not_record": false, "persons": [{"code": "PAXP8L", "name": "Haochen Jiang", "avatar": null, "biography": "Haochen Jiang is Compiler Engineer working for Intel. He mainly worked on new ISA implementation for x86.", "public_name": "Haochen Jiang", "guid": "98ba4ae3-7075-55d1-a779-e86ac69127fd", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/PAXP8L/"}, {"code": "JASWCA", "name": "Venkataramanan Kumar", "avatar": "https://conf.gnu-tools-cauldron.org/media/avatars/VXHSAF_Ul2Gnyq.webp", "biography": "Principal member of technical staff at AMD.  Working in GCC and AOCC compilers.", "public_name": "Venkataramanan Kumar", "guid": "9c5ec66e-2d2a-5a27-99db-12903582cf55", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/JASWCA/"}, {"code": "8NC3SF", "name": "Hongtao Liu", "avatar": "https://conf.gnu-tools-cauldron.org/media/avatars/Y9HARS_Tb9TVSW.webp", "biography": "GCC developer, maintainer of i386 vector ISA extns", "public_name": "Hongtao Liu", "guid": "105bc634-f43a-595a-9fe2-620574516798", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/8NC3SF/"}], "links": [], "feedback_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/L7UHWJ/feedback/", "origin_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/L7UHWJ/", "attachments": [{"title": "Slides for BoF", "url": "/media/prg26/submissions/L7UHWJ/resources/x86_bof_0uXeSCm.pdf", "type": "related"}]}, {"guid": "e2760e3e-812a-55bc-851f-eba4677f4e02", "code": "ALWGLG", "id": 104149, "logo": null, "date": "2026-10-03T11:30:00+02:00", "start": "11:30", "end": "2026-10-03T12:00:00+02:00", "duration": "00:30", "room": "Room S (Floor 3)", "slug": "prg26-104149-towards-real-time-abi-compatibility-assurance-with-libctf", "url": "https://conf.gnu-tools-cauldron.org/prg26/talk/ALWGLG/", "title": "Towards real-time ABI compatibility assurance with libctf", "subtitle": "", "track": null, "type": "Talk (Short)", "language": "en", "abstract": "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?\n\nOne 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.\n\nThe end goal is to be able to see something like this:\n$ emacs\nwarning: libxml.so.2.13.9: incompatible symbol: linked against xmlDocPtr xmlReadMemory (const char *, int, const char *, const char *, int)\nbut running against xmlDocPtr xmlReadMemory (const char *, int, const char *, const char *)\n\n(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.)\n\nThis 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.", "description": "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).", "recording_license": "", "do_not_record": false, "persons": [{"code": "R3HJEU", "name": "Nick Alcock", "avatar": null, "biography": "libctf hacker, DTrace hacker for fifteen years (until this year); interested in debuggers, compilers, Unix-like operating systems, interesting type systems, fun algorithms, and unusual languages (which is no doubt why almost everything serious I've written for the last thirty years seems to have ended up being largely in C...)", "public_name": "Nick Alcock", "guid": "9e8abf74-1874-59ee-b936-6cf9f47a81a8", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/R3HJEU/"}], "links": [], "feedback_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/ALWGLG/feedback/", "origin_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/ALWGLG/", "attachments": []}, {"guid": "f204b7e5-65f1-5f0f-9376-761add7d7631", "code": "3PPGKX", "id": 103143, "logo": null, "date": "2026-10-03T12:00:00+02:00", "start": "12:00", "end": "2026-10-03T12:30:00+02:00", "duration": "00:30", "room": "Room S (Floor 3)", "slug": "prg26-103143-lazy-dynamic-linking-for-linux-deferring-relative-relocations-with-ebpf", "url": "https://conf.gnu-tools-cauldron.org/prg26/talk/3PPGKX/", "title": "Lazy Dynamic Linking for Linux: Deferring Relative Relocations with eBPF", "subtitle": "", "track": null, "type": "Talk (Short)", "language": "en", "abstract": "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 \u2013 `userfaultfd` \u2013 is too slow and requires a handler thread the dynamic linker cannot safely spawn.\n\nThis 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.", "description": "", "recording_license": "", "do_not_record": false, "persons": [{"code": "WPGDUY", "name": "Tal Zussman", "avatar": null, "biography": "Tal Zussman is a PhD student in Computer Science at Columbia University, working on operating systems, eBPF, and memory management.", "public_name": "Tal Zussman", "guid": "7637f325-12d6-5ab3-a1df-66588e038651", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/WPGDUY/"}], "links": [{"title": "Paper", "url": "https://dl.acm.org/doi/pdf/10.1145/3830418.3843896", "type": "related"}, {"title": "Repo", "url": "https://github.com/bpf-fault/bpf-fault", "type": "related"}], "feedback_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/3PPGKX/feedback/", "origin_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/3PPGKX/", "attachments": [{"title": "Slides", "url": "/media/prg26/submissions/3PPGKX/resources/bpf_fault_gnu_817TORj.pdf", "type": "related"}]}, {"guid": "8ea17806-f9f8-5a48-9e2b-59fde6436199", "code": "9PMLD9", "id": 104801, "logo": null, "date": "2026-10-03T13:30:00+02:00", "start": "13:30", "end": "2026-10-03T14:30:00+02:00", "duration": "01:00", "room": "Room S (Floor 3)", "slug": "prg26-104801-arm-aarch64-bof", "url": "https://conf.gnu-tools-cauldron.org/prg26/talk/9PMLD9/", "title": "Arm & AArch64 BoF", "subtitle": "", "track": null, "type": "Birds of a Feather (BoF)", "language": "en", "abstract": "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.", "description": "", "recording_license": "", "do_not_record": false, "persons": [{"code": "HUMFV7", "name": "Andre Vieira", "avatar": null, "biography": "Technology Manager for GNU Toolchain at Arm.", "public_name": "Andre Vieira", "guid": "44d34562-1d2b-5e91-9a17-5c82d30d1380", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/HUMFV7/"}, {"code": "QZCCYF", "name": "Tamar Christina", "avatar": null, "biography": "Compiler Engineer at Arm Holdings", "public_name": "Tamar Christina", "guid": "22832025-3da9-502e-aa5b-5cb6982d51e2", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/QZCCYF/"}], "links": [], "feedback_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/9PMLD9/feedback/", "origin_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/9PMLD9/", "attachments": []}, {"guid": "f73b25fd-5f48-5d20-88b1-f0db379599c2", "code": "AVZDSN", "id": 98225, "logo": null, "date": "2026-10-03T14:30:00+02:00", "start": "14:30", "end": "2026-10-03T15:30:00+02:00", "duration": "01:00", "room": "Room S (Floor 3)", "slug": "prg26-98225-vectorizer-bof", "url": "https://conf.gnu-tools-cauldron.org/prg26/talk/AVZDSN/", "title": "Vectorizer BOF", "subtitle": "", "track": null, "type": "Birds of a Feather (BoF)", "language": "en", "abstract": "Annual BOF on vectorization and related topics with focus on architectural decisions going forward.", "description": "", "recording_license": "", "do_not_record": false, "persons": [{"code": "VWYCY8", "name": "Richard Biener", "avatar": null, "biography": "Working in SUSE Labs on Toolchain.  Release manager, vectorizer, and middle-end maintainer, global reviewer.", "public_name": "Richard Biener", "guid": "3dd461e7-16a7-5e08-ae88-6743c6fc39c9", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/VWYCY8/"}, {"code": "QZCCYF", "name": "Tamar Christina", "avatar": null, "biography": "Compiler Engineer at Arm Holdings", "public_name": "Tamar Christina", "guid": "22832025-3da9-502e-aa5b-5cb6982d51e2", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/QZCCYF/"}, {"code": "BUFWQT", "name": "Robin Dapp", "avatar": null, "biography": "Robin is working on the riscv target with a focus on vectorization and other middle-end topics.", "public_name": "Robin Dapp", "guid": "3f283bb2-90fb-53f7-8df5-e1ca78482ef8", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/BUFWQT/"}], "links": [], "feedback_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/AVZDSN/feedback/", "origin_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/AVZDSN/", "attachments": []}, {"guid": "40d20217-8806-598b-a0ff-8a932b28a7c1", "code": "9QEWWH", "id": 101594, "logo": null, "date": "2026-10-03T16:00:00+02:00", "start": "16:00", "end": "2026-10-03T17:00:00+02:00", "duration": "01:00", "room": "Room S (Floor 3)", "slug": "prg26-101594-risc-v-bof", "url": "https://conf.gnu-tools-cauldron.org/prg26/talk/9QEWWH/", "title": "RISC-V BOF", "subtitle": "", "track": null, "type": "Birds of a Feather (BoF)", "language": "en", "abstract": "Discussion of RISC-V issues.  High level agenda items TBD, but would likely include this areas:\n\n* State of the various tools (gcc, glibc, gdb, valgrind, etc) on RISC-V\n* Overview of optimzation efforts over the last few years + future work\n* Major challenges for the RISC-V community", "description": "", "recording_license": "", "do_not_record": false, "persons": [{"code": "VP7HYH", "name": "Jeff Law", "avatar": null, "biography": "Jeff has been contributing to the GCC project since the late 1980s when he was trying to improve the performance of a port of 4.3BSD on the hp200 series systems (m68k).  Through the years he has worked on most if not all of the RTL optimizers, many target ports, helped design and implement many of the early tree-ssa/gimple optimizers, etc.  Jeff also hosts a regression testing system for the GCC project that tests most targets on a daily basis.", "public_name": "Jeff Law", "guid": "af9470bb-c819-5e1e-80b0-bb83a9b08352", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/VP7HYH/"}, {"code": "BUFWQT", "name": "Robin Dapp", "avatar": null, "biography": "Robin is working on the riscv target with a focus on vectorization and other middle-end topics.", "public_name": "Robin Dapp", "guid": "3f283bb2-90fb-53f7-8df5-e1ca78482ef8", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/BUFWQT/"}], "links": [], "feedback_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/9QEWWH/feedback/", "origin_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/9QEWWH/", "attachments": []}]}}, {"index": 3, "date": "2026-10-04", "day_start": "2026-10-04T04:00:00+02:00", "day_end": "2026-10-05T03:59:00+02:00", "rooms": {"Room S 9": [{"guid": "1c48944f-7ca9-57ac-bd33-5412c20d5de7", "code": "DLBVLV", "id": 105274, "logo": "https://conf.gnu-tools-cauldron.org/media/prg26/submissions/DLBVLV/image_uusP61R.webp", "date": "2026-10-04T09:00:00+02:00", "start": "09:00", "end": "2026-10-04T10:00:00+02:00", "duration": "01:00", "room": "Room S 9", "slug": "prg26-105274-gnu-algol-68-bof", "url": "https://conf.gnu-tools-cauldron.org/prg26/talk/DLBVLV/", "title": "GNU Algol 68 BoF", "subtitle": "", "track": null, "type": "Birds of a Feather (BoF)", "language": "en", "abstract": "The Algol 68 front-end got merged in GCC 16 and is under active\ndevelopment.  In this BoF the ga68 developers will meet and discuss\nabout the current status of the front-end, known issues, achieving ABI\nstability in GCC 17, the design of several features and GNU extensions\nto the language, preludes/libraries, the Algol 68 support in the GNU\nbuild system, the Algol 68 support in GDB, etc.\n\nEveryone is welcome to join this BoF, especially new people wanting to\ncontribute to the toolchain in general and GCC front-ends in\nparticular.", "description": "", "recording_license": "", "do_not_record": false, "persons": [{"code": "9VT7SW", "name": "Jose Marchesi", "avatar": "https://conf.gnu-tools-cauldron.org/media/avatars/NQYMKF_d7jTr5G.webp", "biography": "GNU hacker and maintainer", "public_name": "Jose Marchesi", "guid": "82357286-b437-5022-b27e-e5e9c56c6f87", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/9VT7SW/"}, {"code": "WZ87AU", "name": "pietro", "avatar": null, "biography": "I've been hacking on the GCC Algol 68 frontend.", "public_name": "pietro", "guid": "37c5cd28-c1cc-57da-99fc-b377433e7957", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/WZ87AU/"}, {"code": "RJJ97D", "name": "Mohammad-Reza Nabipoor", "avatar": null, "biography": "Co-maintainer of GNU poke", "public_name": "Mohammad-Reza Nabipoor", "guid": "5f3688d6-caee-50f1-a974-ff3b520f41d5", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/RJJ97D/"}], "links": [], "feedback_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/DLBVLV/feedback/", "origin_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/DLBVLV/", "attachments": []}, {"guid": "594be9db-2c87-5c11-b417-309a9aad34ea", "code": "FXG777", "id": 105070, "logo": null, "date": "2026-10-04T10:30:00+02:00", "start": "10:30", "end": "2026-10-04T11:30:00+02:00", "duration": "01:00", "room": "Room S 9", "slug": "prg26-105070-kcfi-comes-to-gcc-code-reuse-defenses-for-the-linux-kernel", "url": "https://conf.gnu-tools-cauldron.org/prg26/talk/FXG777/", "title": "KCFI Comes to GCC: Code-Reuse Defenses for the Linux Kernel", "subtitle": "", "track": null, "type": "Talk", "language": "en", "abstract": "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.", "description": "", "recording_license": "", "do_not_record": false, "persons": [{"code": "PUF7NN", "name": "Kees Cook", "avatar": null, "biography": "Kees Cook has been working with Free Software since 1994, has been a Debian Developer since 2007, and has been a member of the Linux Kernel Technical Advisory Board since 2019. He is currently employed as a Linux kernel security engineer by Google, focusing on upstream kernel security defenses.\n\nFrom 2006 through 2011 he worked for Canonical as the Ubuntu Security Team's Tech Lead. Before that, he worked as the lead sysadmin at OSDL, before it was the Linux Foundation. He has written various utilities including GOPchop and Sendpage, and contributes randomly to other projects including fun chunks of code in OpenSSH, Inkscape, Wine, MPlayer, and Wireshark.\n\nhttps://hachyderm.io/@kees", "public_name": "Kees Cook", "guid": "3a8ca322-30c6-576c-9d71-3c1ffac6d885", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/PUF7NN/"}], "links": [], "feedback_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/FXG777/feedback/", "origin_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/FXG777/", "attachments": []}, {"guid": "98a17d70-75d5-5323-9d42-51916b14ee79", "code": "98FKUB", "id": 105444, "logo": null, "date": "2026-10-04T11:30:00+02:00", "start": "11:30", "end": "2026-10-04T12:30:00+02:00", "duration": "01:00", "room": "Room S 9", "slug": "prg26-105444-speeding-up-abi-analysis-of-big-elf-dwarf-binaries-with-multi-threading", "url": "https://conf.gnu-tools-cauldron.org/prg26/talk/98FKUB/", "title": "Speeding up ABI analysis of big ELF/DWARF binaries with multi-threading", "subtitle": "", "track": null, "type": "Talk", "language": "en", "abstract": "During Libabigail 3.0 development, the internal representation of the Application Binary Interface is constructed using a set of multi-threaded algorithms.  \n\nThis 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.\n\nThis 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.", "description": "", "recording_license": "", "do_not_record": false, "persons": [{"code": "ZPGJLN", "name": "Dodji Seketeli", "avatar": null, "biography": "Dodji Seketeli is a member of the Platform Tools engineering team at Red Hat.  He currently focuses on Application Binary Interface change analysis tooling across the full life cycle of the Red Hat Enterprise Linux related products.", "public_name": "Dodji Seketeli", "guid": "ab13d7a4-cfe6-5ad7-8673-34c387211d1e", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/ZPGJLN/"}], "links": [], "feedback_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/98FKUB/feedback/", "origin_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/98FKUB/", "attachments": [{"title": "PDF slides", "url": "/media/prg26/submissions/98FKUB/resources/multithreaded-libabi_OhV5mRk.pdf", "type": "related"}]}, {"guid": "da619b18-ff78-564a-b4b5-73b2ca122065", "code": "9ULSQA", "id": 105416, "logo": null, "date": "2026-10-04T13:30:00+02:00", "start": "13:30", "end": "2026-10-04T14:00:00+02:00", "duration": "00:30", "room": "Room S 9", "slug": "prg26-105416-gpu-programming-with-guta-gcc-s-unified-threading-abstraction", "url": "https://conf.gnu-tools-cauldron.org/prg26/talk/9ULSQA/", "title": "GPU programming with GUTA: GCC's Unified Threading Abstraction", "subtitle": "", "track": null, "type": "Talk (Short)", "language": "en", "abstract": "\"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.\n\nWe'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?", "description": "", "recording_license": "", "do_not_record": false, "persons": [{"code": "VRELN7", "name": "Thomas Schwinge", "avatar": "https://conf.gnu-tools-cauldron.org/media/avatars/BX89LB_zvr0heA.webp", "biography": "Software engineer, primarily working on [GCC (GNU Compiler Collection)](https://gcc.gnu.org/), in particular adding support for [OpenACC](https://gcc.gnu.org/wiki/OpenACC)/[OpenMP](https://gcc.gnu.org/wiki/OpenMP) (directive-based parallel programming models) with [code offloading](https://gcc.gnu.org/wiki/Offloading) to Nvidia GPUs (project started in 2013-06), and AMD GPUs.  In 2018-09, appointed GCC/OpenACC maintainer, in 2023-07 appointed GCC/nvptx maintainer.  Active member of the [OpenACC Technical Committee](https://openacc.org/).\n\nPart of the team developing [GCC/Rust](https://rust-gcc.github.io/): a GCC front end for the Rust programming language.\n\nI also worked on glibc, GDB, binutils, etc., and had a brief look into the world of LLVM, but GCC etc. is still keeping me busy.\n\nEmployed by [BayLibre](https://baylibre.com/).\n\nBackground in electrical engineering, focus on computer engineering, graduating from the Universit\u00e4t Stuttgart with a Diplom-Ingenieur (Dipl.-Ing., compare to M.Eng.) degree.\n\n  * <https://fosstodon.org/@tschwinge>\n  * <https://bsky.app/profile/tschwinge.bsky.social>\n  * <https://twitter.com/schwinge_thomas>\n  * <https://www.linkedin.com/in/tschwinge>\n  * <https://github.com/tschwinge/>", "public_name": "Thomas Schwinge", "guid": "417937df-487e-514d-90a9-420f86d2db50", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/VRELN7/"}], "links": [], "feedback_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/9ULSQA/feedback/", "origin_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/9ULSQA/", "attachments": [{"title": "'GNU Tools Cauldron 2026 - GPU programming with GUTA_ GCC's Unified Threading Abstraction.pdf'", "url": "/media/prg26/submissions/9ULSQA/resources/GNU_Tools_Cauldron_2_jdrV5aU.pdf", "type": "related"}]}, {"guid": "2c7c7409-9657-536a-b38d-be80df6f6061", "code": "TRZN7Z", "id": 105272, "logo": null, "date": "2026-10-04T14:00:00+02:00", "start": "14:00", "end": "2026-10-04T15:00:00+02:00", "duration": "01:00", "room": "Room S 9", "slug": "prg26-105272-toolchain-and-linux-kernel-bof", "url": "https://conf.gnu-tools-cauldron.org/prg26/talk/TRZN7Z/", "title": "Toolchain and Linux Kernel BoF", "subtitle": "", "track": null, "type": "Birds of a Feather (BoF)", "language": "en", "abstract": "The Linux kernel, which is by far one of the biggest, more complex and\nmore important free software programs around, is (still) mainly built\nusing the GNU Toolchain.\n\nThere is an intimate relationship between toolchain and kernel.\n\nCompiling a huge, complex and specialized program such as the kernel\noften implies facing challenging or unusual requirements on the\ntoolchain side. This includes security related requirements. Also,\nsome of the toolchain components interface directly with the\nkernel. In the case of glibc, it even provides the main visible\ninterface from the kernel to userland programs. The support for BPF is\nalso mainly Linux kernel specific.\n \nThis relationship benefits both projects. For example, an actively\nmaintained toolchain can quickly include kernel specific\nenhancements. And vice versa, the toolchain benefits from the\nassociated relevance that makes corporations support its\ndevelopment. It is certainly not unusual for a feature introduced\nprimarily for kernel usage to also be very useful to other\nprograms. Examples of this are the support for patchable function\nentries, \"asm goto\", fentry , and several security related features.\n \nIn order to improve this relationship a Toolchains Track has been\norganized for some years now at the Linux PLumbers Conference. The aim\nof the track is to fix particular toolchain (both GNU and LLVM) issues\nwhich are of interest to the kernel and, ideally, find and agree on\nsolutions right away, during the track, making the best use of the\nopportunity to discuss the issues live with kernel developers and\nmaintainers. The LPC toolchains track is proving very useful, although\nit is not always easy to bring toolchain hackers there, given it is a\nkernel specific conference.\n \nWe propose to have a Toolchain and Linux Kernel BoF during Cauldron\nthis year, as we did last year, with the participation of several\nLinux kernel maintainers. The goals of the BoF are (a) to discuss\nabout particular requirements, desired features and on-going\ndevelopments that are relevant to the kernel and (b) to gather kernel\nrelated questions/input/feedback from the toolchain developers so we\ncan bring the issues to the LPC Toolchains Track, which will be held\nimmediately after Cauldron, also in Prague.", "description": "", "recording_license": "", "do_not_record": false, "persons": [{"code": "9VT7SW", "name": "Jose Marchesi", "avatar": "https://conf.gnu-tools-cauldron.org/media/avatars/NQYMKF_d7jTr5G.webp", "biography": "GNU hacker and maintainer", "public_name": "Jose Marchesi", "guid": "82357286-b437-5022-b27e-e5e9c56c6f87", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/9VT7SW/"}, {"code": "MQMRDF", "name": "Miguel Ojeda", "avatar": "https://conf.gnu-tools-cauldron.org/media/avatars/GNYNW8_4P4zhjZ.webp", "biography": "Miguel Ojeda is a software engineer who leads the Rust for Linux project. He is a member of the Linux Foundation Technical Advisory Board. He was the Spanish NB in the ISO C committee, with an interest in Undefined Behavior and memory safety topics. Previously, Miguel was a Staff Member at CERN in the Beams department and a Fellow in the Physics department.", "public_name": "Miguel Ojeda", "guid": "4fd1bbe4-4f88-56bc-8a27-d9ee5960cd6a", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/MQMRDF/"}, {"code": "QQ8RFW", "name": "Alexei", "avatar": null, "biography": "All things BPF", "public_name": "Alexei", "guid": "e7b6b1b2-8527-593b-bd9c-20dbbc4c7669", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/QQ8RFW/"}, {"code": "FNFDBW", "name": "Alejandro Colomar", "avatar": null, "biography": "Maintainer of the Linux man-pages.\nCo-maintainer of shadow-utils.\nCo-maintainer of mutt(1).\nMember of the C Committee.", "public_name": "Alejandro Colomar", "guid": "f2d2eb76-4e79-5d00-9248-2d9bd80839cd", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/FNFDBW/"}, {"code": "HHEN9T", "name": "Paul McKenney", "avatar": "https://conf.gnu-tools-cauldron.org/media/avatars/WHFFCW_BT7CAuv.webp", "biography": "Paul E. McKenney is a software engineer at Meta Platforms, and has been coding for almost half a century, with more than half of that on multicore hardware. Paul is lead maintainer of the RCU implementation within the Linux kernel, where the variety of workloads present highly entertaining performance, scalability, real-time response, and energy-efficiency challenges.  Paul also is lead maintainer for the Linux-kernel memory model (LKMM).\n\nPaul previously worked for IBM LTC, Sequent Computer Systems, SRI International, himself, and the Oregon State University Computer Center, with his work having migrated from the upper reaches of the application stack to the lower reaches of the Linux kernel.\n\nHe received bachelors degrees in Mechanical Engineering and in Computer Science and a masters degree in Computer Science, all from Oregon State University, along with a Ph.D. in Computer Science and Engineering from the OGI School of Science & Engineering at Oregon Health & Science University. He holds more than 100 patents and has a few hundred publications, perhaps most notably a freely downloadable book entitled \u201cIs Parallel Programming Hard, And If So, What Can You Do About It?\u201d, which has been used in university courses and translated into Korean, Chinese, Japanese, and Russian. His hobbies include hiking and gym workouts along with the usual house-wife-and-grown-kids habit.", "public_name": "Paul McKenney", "guid": "9c2efbfc-c1c6-559e-8a9a-ae94f3c3b856", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/HHEN9T/"}, {"code": "UGBFNA", "name": "Nick Desaulniers", "avatar": null, "biography": null, "public_name": "Nick Desaulniers", "guid": "4b16e975-8758-56fb-9fb0-4c36c02f778a", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/UGBFNA/"}], "links": [], "feedback_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/TRZN7Z/feedback/", "origin_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/TRZN7Z/", "attachments": []}], "Room S 5": [{"guid": "655b4648-ca31-54bf-8626-c6100ab93c50", "code": "8CDLKZ", "id": 104155, "logo": null, "date": "2026-10-04T09:00:00+02:00", "start": "09:00", "end": "2026-10-04T10:00:00+02:00", "duration": "01:00", "room": "Room S 5", "slug": "prg26-104155-practical-ipa-points-to-with-steensgaard-s-algorithm-why-how-and-what-s-the-status", "url": "https://conf.gnu-tools-cauldron.org/prg26/talk/8CDLKZ/", "title": "Practical IPA points-to with Steensgaard's algorithm? Why, how and what's the status", "subtitle": "", "track": null, "type": "Talk", "language": "en", "abstract": "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.\n\nHowever, 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.\n\nI'll introduce the project and talk about all the interesting problems I've encountered, possible solutions, and other future plans.", "description": "", "recording_license": "", "do_not_record": false, "persons": [{"code": "N9PHWC", "name": "Filip Kastl", "avatar": "https://conf.gnu-tools-cauldron.org/media/avatars/RTG9LU_fsXozte.webp", "biography": "Compiler engineer at SUSE. I'm still relatively new to GCC and I live primarily in the GIMPLE optimization pipeline. I'm responsible for the SCCOPY pass, I dabbled in switch statement optimizations, and currently I'm immersed in points-to analysis. I may also pester you about errors and benchmark regressions I tracked down to your GCC commit since I help monitor SUSE's automated builders.", "public_name": "Filip Kastl", "guid": "996449ee-6d1b-52dc-aaf4-b04ed51bd2c0", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/N9PHWC/"}], "links": [], "feedback_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/8CDLKZ/feedback/", "origin_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/8CDLKZ/", "attachments": [{"title": "Presentation slides", "url": "/media/prg26/submissions/8CDLKZ/resources/presentation_8sCdwpL.pdf", "type": "related"}]}, {"guid": "84839e75-f8cb-5d7b-bab9-e62ae0d29fe5", "code": "7LR8AS", "id": 104461, "logo": null, "date": "2026-10-04T10:30:00+02:00", "start": "10:30", "end": "2026-10-04T11:30:00+02:00", "duration": "01:00", "room": "Room S 5", "slug": "prg26-104461-mesa-the-middle-end-semantic-assembler", "url": "https://conf.gnu-tools-cauldron.org/prg26/talk/7LR8AS/", "title": "MESA: the middle-end semantic assembler", "subtitle": "", "track": null, "type": "Talk", "language": "en", "abstract": "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.  \n\nMESA 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.  \n\nTo the author's knowledge, MESA is novel compiler technology.", "description": "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.  \n\nWhen 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. \n\nTo 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.  \n\nMESA 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.", "recording_license": "", "do_not_record": false, "persons": [{"code": "NLDS8E", "name": "James K. Lowden", "avatar": "https://conf.gnu-tools-cauldron.org/media/avatars/TQFVKJ_QZsQuOq.webp", "biography": "James worked for many years on Wall Street on quantitative research systems, implementing algorithms and designing databases to support them.  For a decade he was the maintainer for FreeTDS (www.freetds.org), a client library for SQL Server.  For the last several years, he's been extending gcc to recognize COBOL, with the (so far) secret ambition of enticing mainframe shops to embrace GCC and Linux.", "public_name": "James K. Lowden", "guid": "7abcf44e-77e3-5494-926d-aa7e4053d00f", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/NLDS8E/"}], "links": [], "feedback_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/7LR8AS/feedback/", "origin_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/7LR8AS/", "attachments": []}, {"guid": "3f2561e4-85eb-57e1-b121-244d207abd9c", "code": "QAQXDB", "id": 105225, "logo": null, "date": "2026-10-04T11:30:00+02:00", "start": "11:30", "end": "2026-10-04T12:30:00+02:00", "duration": "01:00", "room": "Room S 5", "slug": "prg26-105225-toolchain-licensing-bof", "url": "https://conf.gnu-tools-cauldron.org/prg26/talk/QAQXDB/", "title": "Toolchain Licensing BoF", "subtitle": "", "track": null, "type": "Birds of a Feather (BoF)", "language": "en", "abstract": "The GNU toolchain packages are not only the showcase for the most\nexcellent toolchain software ever written. They are also the showcase\nof the inventive licensing structure known as copyleft. The toolchain\ncommunity is often at the forefront of licensing questions and\nconcerns.\n\nThis BoF session will be an open discussion about many of the\nquestions/concerns that were raised at and since last year's Cauldron\n(and elsewhere in community discussions).  Discussion will include any\nadditional topic that toolchain maintainers and hackers may be\ninterested in discussing.\n\nSome examples of items raised since last year's Cauldron that will be\ndiscussed include:\n\n* Scenarios and topics concerning copyright assignment and\n      code-sharing in different GNU packages and lessons we can all\n      learn from here.\n\n* Discussion of current GNU & FSF policies on acceptance of (whole or\n      in part) LLM-gen-AI generated code in the toolchain packages\n      and what are current package-specific challenges, discussion of\n      work SFC has done with its projects on LLM-gen-AI policies,\n      and the complementary work that FSF and SFC are doing\n      to navigate this difficult era of LLM-gen-AI contributions.\n \n* What are the best ways to welcome new contributors to the GNU\ntoolchain given their varying usage of LLM-gen-AI tools?\n\n* Any questions about the GCC RTL Exception that the audience has.", "description": "", "recording_license": "", "do_not_record": false, "persons": [{"code": "QUXAAH", "name": "Denver Gingerich", "avatar": "https://conf.gnu-tools-cauldron.org/media/avatars/ZLXMXV_Z4mpA5D.webp", "biography": "Denver is a software right-to-repair and standards activist who is currently Director for Digital Autonomy at Software Freedom Conservancy, where he enforces software right-to-repair licenses such as the GPL, and is also a director of the worker co-operative that runs JMP.chat, a FOSS phone number (texting/calling) service.  Denver writes free software in his spare time: his patches have been accepted into Wine, Linux, and wdiff.  He gives presentations about digital civil rights and how to ensure FOSS remains sustainable as a community and financially, having spoken at conferences such as FOSSY, SCALE, the Canadian Repair Convention, FOSDEM, SFSCON, CopyleftConf, WineConf, LibrePlanet, Linux Plumbers Conference, CopyCamp Toronto, FOSSLC's Summercamp, and the Open Video Conference.", "public_name": "Denver Gingerich", "guid": "f731edbc-7b30-5d53-b813-52e7bf244a2c", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/QUXAAH/"}, {"code": "9QDEAG", "name": "Ian Kelling", "avatar": "https://conf.gnu-tools-cauldron.org/media/avatars/XE9RUP_YzounP2.webp", "biography": "Ian is President of the Free Software Foundation (FSF) and works at FSF as a Senior Systems Administrator. He discovered free software while studying for his bachelor's degree in computer science in 2006. Early in his software career, he experienced working as a software developer for proprietary software companies, while using, learning, and contributing to GNU/Linux on his own time, which solidified his personal belief in complete software freedom. He started working at FSF in 2017, joined the FSF board in 2021, and became FSF president in 2025. He has contributed to pieces of free software like GNU Emacs, community efforts like the Free Software Directory and others, and has been a speaker at the Seattle GNU/Linux conference (SeaGL) and FOSDEM.", "public_name": "Ian Kelling", "guid": "68460385-3ba8-5bef-b867-70050738b339", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/9QDEAG/"}], "links": [], "feedback_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/QAQXDB/feedback/", "origin_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/QAQXDB/", "attachments": []}, {"guid": "4b0b36e7-9869-5eeb-9946-320180f444cb", "code": "SVVBRS", "id": 105323, "logo": "https://conf.gnu-tools-cauldron.org/media/prg26/submissions/SVVBRS/image_ceQkiXK.webp", "date": "2026-10-04T13:30:00+02:00", "start": "13:30", "end": "2026-10-04T14:30:00+02:00", "duration": "01:00", "room": "Room S 5", "slug": "prg26-105323-sourceware-infrastructure-organization-and-automation", "url": "https://conf.gnu-tools-cauldron.org/prg26/talk/SVVBRS/", "title": "Sourceware Infrastructure Organization and Automation", "subtitle": "", "track": null, "type": "Talk", "language": "en", "abstract": "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.\n\nMore 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.\n\nFor 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.", "description": "- 20 minutes Overview of available Sourceware resources, automating your CI processes\n    (buildbots, try-bots, pre/post-commit-CI/CD, snapshots, forgejo runners, patchwork's curator, etc.)\n- 20 minutes introduction to the Sourceware organization and goals for next year\n- 20 minutes Q&A with Sourceware PLC, FSF and SFC staff\n\nhttps://builder.sourceware.org\nhttps://sourceware.org/financials.html\nhttps://sourceware.org/sourceware-wiki/servers-and-services-2026/", "recording_license": "", "do_not_record": false, "persons": [{"code": "QRUGJS", "name": "Mark J. Wielaard", "avatar": null, "biography": "Red Hat, Senior Principal Software Engineer, Platform Tools\nHe / Him / His\n\nDebugedit, Elfutils, Valgrind maintainer\nSourceware Project Leadership Committee Member\nDWARF Debugging Information Format Committee Member", "public_name": "Mark J. Wielaard", "guid": "d7a08ae1-ec0c-5343-abc9-f3577676070c", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/QRUGJS/"}, {"code": "QUXAAH", "name": "Denver Gingerich", "avatar": "https://conf.gnu-tools-cauldron.org/media/avatars/ZLXMXV_Z4mpA5D.webp", "biography": "Denver is a software right-to-repair and standards activist who is currently Director for Digital Autonomy at Software Freedom Conservancy, where he enforces software right-to-repair licenses such as the GPL, and is also a director of the worker co-operative that runs JMP.chat, a FOSS phone number (texting/calling) service.  Denver writes free software in his spare time: his patches have been accepted into Wine, Linux, and wdiff.  He gives presentations about digital civil rights and how to ensure FOSS remains sustainable as a community and financially, having spoken at conferences such as FOSSY, SCALE, the Canadian Repair Convention, FOSDEM, SFSCON, CopyleftConf, WineConf, LibrePlanet, Linux Plumbers Conference, CopyCamp Toronto, FOSSLC's Summercamp, and the Open Video Conference.", "public_name": "Denver Gingerich", "guid": "f731edbc-7b30-5d53-b813-52e7bf244a2c", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/QUXAAH/"}, {"code": "9QDEAG", "name": "Ian Kelling", "avatar": "https://conf.gnu-tools-cauldron.org/media/avatars/XE9RUP_YzounP2.webp", "biography": "Ian is President of the Free Software Foundation (FSF) and works at FSF as a Senior Systems Administrator. He discovered free software while studying for his bachelor's degree in computer science in 2006. Early in his software career, he experienced working as a software developer for proprietary software companies, while using, learning, and contributing to GNU/Linux on his own time, which solidified his personal belief in complete software freedom. He started working at FSF in 2017, joined the FSF board in 2021, and became FSF president in 2025. He has contributed to pieces of free software like GNU Emacs, community efforts like the Free Software Directory and others, and has been a speaker at the Seattle GNU/Linux conference (SeaGL) and FOSDEM.", "public_name": "Ian Kelling", "guid": "68460385-3ba8-5bef-b867-70050738b339", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/9QDEAG/"}], "links": [], "feedback_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/SVVBRS/feedback/", "origin_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/SVVBRS/", "attachments": [{"title": "Talk slides", "url": "/media/prg26/submissions/SVVBRS/resources/Sourceware-Cauldron-_7FQ0SPp.pdf", "type": "related"}]}], "Room S (Floor 3)": [{"guid": "3fc163f9-50af-588a-97a0-739ec4c58e66", "code": "TPLVAA", "id": 101593, "logo": null, "date": "2026-10-04T09:00:00+02:00", "start": "09:00", "end": "2026-10-04T10:00:00+02:00", "duration": "01:00", "room": "Room S (Floor 3)", "slug": "prg26-101593-using-llms-in-patch-generation-patch-review-and-code-analysis", "url": "https://conf.gnu-tools-cauldron.org/prg26/talk/TPLVAA/", "title": "Using LLMs in patch generation, patch review and code analysis", "subtitle": "", "track": null, "type": "Talk", "language": "en", "abstract": "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?\n\nWe 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.\n\nThe 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.", "description": "", "recording_license": "", "do_not_record": false, "persons": [{"code": "VP7HYH", "name": "Jeff Law", "avatar": null, "biography": "Jeff has been contributing to the GCC project since the late 1980s when he was trying to improve the performance of a port of 4.3BSD on the hp200 series systems (m68k).  Through the years he has worked on most if not all of the RTL optimizers, many target ports, helped design and implement many of the early tree-ssa/gimple optimizers, etc.  Jeff also hosts a regression testing system for the GCC project that tests most targets on a daily basis.", "public_name": "Jeff Law", "guid": "af9470bb-c819-5e1e-80b0-bb83a9b08352", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/VP7HYH/"}], "links": [], "feedback_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/TPLVAA/feedback/", "origin_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/TPLVAA/", "attachments": []}, {"guid": "866f1f6c-0b2a-55a4-bde8-0394c35363fa", "code": "XTNMU3", "id": 104672, "logo": null, "date": "2026-10-04T10:30:00+02:00", "start": "10:30", "end": "2026-10-04T11:30:00+02:00", "duration": "01:00", "room": "Room S (Floor 3)", "slug": "prg26-104672-working-groups-in-gcc", "url": "https://conf.gnu-tools-cauldron.org/prg26/talk/XTNMU3/", "title": "Working Groups in GCC", "subtitle": "", "track": null, "type": "Birds of a Feather (BoF)", "language": "en", "abstract": "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.", "description": "", "recording_license": "", "do_not_record": false, "persons": [{"code": "VZRLNM", "name": "Sudi", "avatar": "https://conf.gnu-tools-cauldron.org/media/avatars/V3SYHB_GFJyLnv.webp", "biography": "Sudi is an engineering manager taking care of the GNU Toolchain Team as well as the LLVM Team at Arm. She started her career with compilers and GCC at IIT Bombay in 2013 as a research assistant and continued working on GCC at Ericsson and later at Arm.", "public_name": "Sudi", "guid": "676fb6ea-dcc0-5824-bcdf-8ff3d62acce2", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/VZRLNM/"}, {"code": "9EWN7Q", "name": "Jason Merrill", "avatar": null, "biography": "G++ Maintainer\nGCC Steering Committee", "public_name": "Jason Merrill", "guid": "d311bf01-a529-5e5b-b41a-3febf14e2352", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/9EWN7Q/"}, {"code": "AJ3FMZ", "name": "Carlos O'Donell", "avatar": "https://conf.gnu-tools-cauldron.org/media/avatars/XJPLRH_ZJDiL4H.webp", "biography": "Upstream glibc developer with 20+ years of project experience.\n\nOne of 8 GNU Project package maintainers for glibc.\n\nDownstream distribution developer for Fedora, CentOS Stream and Red Hat Enterprise Linux.\n\nBringing a \"distribution\" perspective to upstream conversations.", "public_name": "Carlos O'Donell", "guid": "ebfff59c-9e64-5083-a2c4-596403479598", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/AJ3FMZ/"}, {"code": "ZLMMQW", "name": "David Edelsohn", "avatar": null, "biography": "Member of the GCC Steering Committee", "public_name": "David Edelsohn", "guid": "0dd20b93-b006-5439-a276-2d778d545055", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/ZLMMQW/"}], "links": [], "feedback_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/XTNMU3/feedback/", "origin_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/XTNMU3/", "attachments": []}, {"guid": "1c800649-3f5c-5f2c-a80f-d2e79817f574", "code": "KKJKZK", "id": 104827, "logo": null, "date": "2026-10-04T11:30:00+02:00", "start": "11:30", "end": "2026-10-04T12:30:00+02:00", "duration": "01:00", "room": "Room S (Floor 3)", "slug": "prg26-104827-converting-amd-gcn-to-simt-vectorization", "url": "https://conf.gnu-tools-cauldron.org/prg26/talk/KKJKZK/", "title": "Converting AMD GCN to SIMT vectorization", "subtitle": "", "track": null, "type": "Talk", "language": "en", "abstract": "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.\n\nThe 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.", "description": "", "recording_license": "", "do_not_record": false, "persons": [{"code": "Z3KUDY", "name": "Andrew Stubbs", "avatar": null, "biography": "Compiler Engineer/Sourcerer at BayLibre. GCC maintainer for the AMD GCN GPU architecture. Actively, if not always publicly, working on GCC and GNU Toolchain since 2001, through ST, SuperH, CodeSourcery, Mentor Graphics, Siemens, and now BayLibre.", "public_name": "Andrew Stubbs", "guid": "d1061dc8-3dc1-59d3-9134-9b1838d0e96f", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/Z3KUDY/"}], "links": [], "feedback_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/KKJKZK/feedback/", "origin_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/KKJKZK/", "attachments": [{"title": "Presentation slides", "url": "/media/prg26/submissions/KKJKZK/resources/Converting_GCN_to_SI_PORyyAp.pdf", "type": "related"}]}, {"guid": "1c507f52-b30c-58df-8a10-86a68106f180", "code": "3HWNAL", "id": 105318, "logo": null, "date": "2026-10-04T13:30:00+02:00", "start": "13:30", "end": "2026-10-04T14:00:00+02:00", "duration": "00:30", "room": "Room S (Floor 3)", "slug": "prg26-105318-elfutils-the-road-to-thread-safety", "url": "https://conf.gnu-tools-cauldron.org/prg26/talk/3HWNAL/", "title": "Elfutils: The Road to Thread Safety", "subtitle": "", "track": null, "type": "Talk (Short)", "language": "en", "abstract": "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.", "description": "", "recording_license": "", "do_not_record": false, "persons": [{"code": "P3JDN8", "name": "Aaron Merey", "avatar": null, "biography": "Software developer at Red Hat and elfutils maintainer.", "public_name": "Aaron Merey", "guid": "088d9746-4a80-5ece-a8bd-8cf4a5dd3b65", "url": "https://conf.gnu-tools-cauldron.org/prg26/speaker/P3JDN8/"}], "links": [], "feedback_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/3HWNAL/feedback/", "origin_url": "https://conf.gnu-tools-cauldron.org/prg26/talk/3HWNAL/", "attachments": []}]}}]}}}