While this seems to be a legitimate warning, it's beyond my ability to debug in the SWOC code and I have (for Fedora rawhide) chosen to ignore the warning with "-Wno-error=maybe-uninitialized". It's not a new problem but GCC 16 probably has better checking due to new optimization frameworks.
Should someone who is more familiar with SWOC (and modern C++) wish to debug in the future, this was the feedback I got from our glibc lead: I suspect SR.8029 comes from the scalar replacement of aggregates (SRA) pass. It replaces structs/classes with individual variables. The number is an internal thing to make it unique. If you compile the file with -fdump-tree-sra, it may contain some log data to show where the variable originally came from. However, figuring out where these middle-end warnings come from can be quite difficult. They also tend to have lots of false positives. --Jered ----- On Feb 8, 2026, at 9:42 PM, Jered Floyd [email protected] wrote: > This will not build on Fedora Rawhide for some obscure GCC 16 issue that I'm > stumped by; I will look with fresh eyes later but if anyone wants to make a > guess, I'm including the error below. GCC 16 also requires this patch: > > --- include/tsutil/Regex.h 2026-02-09 02:20:16.441449612 +0000 > +++ include/tsutil/Regex.h 2026-02-09 02:20:43.974279317 +0000 > @@ -27,6 +27,7 @@ > #include <string> > #include <vector> > #include <memory> > +#include <cstdint> > > /// @brief Match flags for regular expression evaluation. > /// > > > Mystery GCC 16 error: > > In file included from > /builddir/build/BUILD/trafficserver-10.1.1-build/trafficserver-10.1.1/lib/swoc/include/swoc/swoc_ip.h:21, > from > > /builddir/build/BUILD/trafficserver-10.1.1-build/trafficserver-10.1.1/lib/swoc/unit_tests/test_ip.cc:15: > In copy constructor > ‘swoc::_1_5_13::IPRangeView::storage_type::storage_type(const > swoc::_1_5_13::IPRangeView::storage_type&)’, > inlined from ‘swoc::_1_5_13::IPRangeView::IPRangeView(const > swoc::_1_5_13::IPRangeView&)’ at > > /builddir/build/BUILD/trafficserver-10.1.1-build/trafficserver-10.1.1/lib/swoc/include/swoc/IPRange.h:604:7, > inlined from > > ‘swoc::_1_5_13::detail::ip_space_const_value_type<C_A_T_C_H_T_E_S_T_15()::Thing>::ip_space_const_value_type(const > > swoc::_1_5_13::detail::ip_space_const_value_type<C_A_T_C_H_T_E_S_T_15()::Thing>&)’ > at > > /builddir/build/BUILD/trafficserver-10.1.1-build/trafficserver-10.1.1/lib/swoc/include/swoc/IPRange.h:979:36, > inlined from > ‘swoc::_1_5_13::IPSpace<PAYLOAD>::const_iterator::const_iterator(const > self_type&) [with PAYLOAD = C_A_T_C_H_T_E_S_T_15()::Thing]’ at > > /builddir/build/BUILD/trafficserver-10.1.1-build/trafficserver-10.1.1/lib/swoc/include/swoc/IPRange.h:1238:5, > inlined from ‘swoc::_1_5_13::IPSpace<PAYLOAD>::const_iterator > swoc::_1_5_13::IPSpace<PAYLOAD>::end() const [with PAYLOAD = > C_A_T_C_H_T_E_S_T_15()::Thing]’ at > > /builddir/build/BUILD/trafficserver-10.1.1-build/trafficserver-10.1.1/lib/swoc/include/swoc/IPRange.h:2556:45, > inlined from ‘swoc::_1_5_13::IPSpace<PAYLOAD>::const_iterator > swoc::_1_5_13::IPSpace<PAYLOAD>::find(const swoc::_1_5_13::IP4Addr&) const > [with PAYLOAD = C_A_T_C_H_T_E_S_T_15()::Thing]’ at > > /builddir/build/BUILD/trafficserver-10.1.1-build/trafficserver-10.1.1/lib/swoc/include/swoc/IPRange.h:2644:20: > /builddir/build/BUILD/trafficserver-10.1.1-build/trafficserver-10.1.1/lib/swoc/include/swoc/IPRange.h:1860:89: > error: ‘SR.8029’ may be used uninitialized [-Werror=maybe-uninitialized] > 1860 | inline > IPRangeView::storage_type::storage_type(IPRangeView::storage_type > const &that) : _void(that._void) {} > | > ^~~~~~~~~~~~~~~~~ > /builddir/build/BUILD/trafficserver-10.1.1-build/trafficserver-10.1.1/lib/swoc/include/swoc/IPRange.h: > In member function ‘swoc::_1_5_13::IPSpace<PAYLOAD>::const_iterator > swoc::_1_5_13::IPSpace<PAYLOAD>::find(const swoc::_1_5_13::IP4Addr&) const > [with PAYLOAD = C_A_T_C_H_T_E_S_T_15()::Thing]’: > /builddir/build/BUILD/trafficserver-10.1.1-build/trafficserver-10.1.1/lib/swoc/include/swoc/IPRange.h:2556:44: > note: ‘SR.8029’ was declared here > 2556 | return const_cast<self_type *>(this)->end(); > | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~ > > > --Jered > > ----- On Feb 3, 2026, at 5:30 PM, Bryan Call [email protected] wrote: > >> +1 >> >> Built and tested on: >> - OS: Fedora Linux 43 (Server Edition) >> - Compiler: gcc (GCC) 15.2.1 20251211 (Red Hat 15.2.1-5) >> >> Results: >> - SHA512 checksum: PASS >> - GPG signature: PASS (signed by Chris McFarlen) >> - Build: PASS >> - Unit tests: PASS >> - Regression: PASS (213 tests, 0 failures) >> >> -Bryan >> >> >>> On Jan 29, 2026, at 11:36 AM, Chris McFarlen <[email protected]> wrote: >>> >>> There was a problem with RC0 that required picking a commit from master. >>> Please >>> retest and vote! >>> >>> I've prepared a release for 10.1.1. The release notes are available at: >>> >>> https://github.com/apache/trafficserver/milestone/90?closed=1 >>> https://docs.trafficserver.apache.org/en/latest/release-notes/whats-new.en.html >>> >>> or for a brief ChangeLog: >>> >>> https://github.com/apache/trafficserver/blob/10.1.x/CHANGELOG-10.1.1 >>> >>> The artifacts are available for download at: >>> >>> https://dist.apache.org/repos/dist/dev/trafficserver/10.1.1 >>> >>> SHA512 checksum: >>> >>> f086354b0d2b361a8bd2dce078ee5cfe7d29a8f1400b63940d4796352ce2bf62a03a212d1939f1b99fc9c5a0b31f29374f86a4dc00c4d655d1f311c0c1449ac5 >>> >>> This corresponds to git refs: >>> >>> Hash: 492ab3b9786547c5c33436890b85c8867a965aa8 >>> Tag: 10.1.1-rc1 >>> >>> Which can be verified with the following command: >>> >>> $ git tag -v 10.1.1-rc1 >>> >>> All code signing keys are available here: >>> >>> https://downloads.apache.org/trafficserver/KEYS >>> >>> Make sure you refresh from a key server to get all relevant signatures >>> >>> Please test and cast your votes as early as possible. >>> >>> -Chris >>> > > > Sent with [Proton Mail](https://proton.me/mail/home) secure email.
