Fedora 45 will ship the same x86-64 baseline it has shipped for years. The Fedora Engineering and Steering Committee rejected the change proposal to build a parallel set of x86-64-v3 packages, the ones that could assume AVX and AVX2, FMA and BMI2, and asked for more performance data plus a plan for install media before it will look again, with Fedora 46 as the earliest realistic target. That is a year of delay for a change that RHEL 10 already made outright, and one that Microsoft wants for the Fedora based Azure Linux. The interesting part is why the committee said no.
The short answer
The Fedora Engineering and Steering Committee has rejected the change that would have built a second set of packages at the x86-64-v3 feature level for Fedora 45, alongside the existing baseline. FESCo wants more performance data and a worked out answer on install media before it reconsiders, and has invited resubmission for Fedora 46. RHEL 10 already requires x86-64-v3, and Microsoft has an interest here through Azure Linux, which is built on Fedora.
Fedora has spent months debating whether to compile its packages for hardware from the last decade rather than hardware from 2003. On Tuesday the answer came back: not this year.
What was on the table
The proposal was more careful than the headline suggests. It did not ask Fedora to drop support for older processors. It asked for an additional, parallel set of packages built at the x86-64-v3 feature level, with the existing x86-64 baseline kept in place for anyone on a dated machine.
x86-64-v3 is the third of the four micro-architecture levels the industry agreed on so distributions could stop enumerating CPU models. It assumes AVX and AVX2, FMA, BMI and BMI2, MOVBE and XSAVE, which lines up with Intel Haswell and newer or AMD Excavator and newer. Roughly speaking, an x86 machine from the past decade qualifies.
The delivery model was designed to be invisible. Per the change page, Release Engineering would publish v3 repositories and images, and DNF5 would transparently select the v3 build on a system that supports the baseline. The engineering work behind that invisibility was not small: extending Koji to do the extra builds, adding the compiler flags to redhat-rpm-config, teaching DNF5 the selection logic, and updating Pungi so composes can be generated. It was owned by Lleyton Gray, Kyle Gospodnetich and Owen Zimmerman, targeted at Fedora Linux 45, and tracked in Release Engineering ticket 13310.
Why the committee refused
FESCo did not argue that v3 packages are a bad idea. It argued that the case had not been made, on two specific points.
The first is data. The committee had been waiting for performance measurements strong enough to justify roughly doubling part of the build and compose pipeline, and what arrived was not enough to decide on. The second is install media. Once two package sets exist, an installer image still has to boot on the old baseline, then work out which set to lay down, and the matrix of images and composes to build, test and mirror grows accordingly. FESCo asked for a worked answer on that before it moves.
Both are the sort of objection that is easy to read as bureaucratic and is usually not. A distribution wide baseline change is a one way door for the release it lands in, and the cost is paid by release engineering and by every mirror operator, in perpetuity.
The part nobody has measured well
The honest answer on the gains is that they vary enormously, which is exactly why the data request is reasonable.
Code that vectorises cleanly can benefit meaningfully from a v3 target, and BMI2 bit manipulation shows up in compression, parsing and hashing. But a great deal of what a distribution ships is glue: configuration handling, string work, I/O bound tooling. Those do not move because you told the compiler about AVX2.
There is a second effect that cuts the expected gain further, and it gets underweighted in these debates. The libraries where SIMD matters most, and the hot paths in things like OpenSSL, glibc's string routines and video codecs, already do runtime dispatch: they check CPU features when they load and jump to the optimised implementation. On those paths your machine has been running v3 or better code for years, whatever the package was compiled for. What a v3 baseline adds is the long tail, everything nobody hand optimised. That tail is worth something across a whole system, but it is precisely the kind of diffuse improvement that needs careful measurement rather than a benchmark of the one workload that shows it best.
Who wanted it, and who already has it
The pressure is not coming from enthusiasts alone. RHEL 10 already requires x86-64-v3 as its floor, which Red Hat justified on the same grounds: virtually every Intel or AMD system deployed in the last ten years clears the bar. Microsoft has an interest too, since the new Azure Linux base is built on Fedora and an x86-64-v3 baseline suits its purposes. Performance oriented distributions such as CachyOS have been shipping optimised builds for a while, which is a real world data point even if it is not a controlled one.
So the direction of travel is not in question. Fedora rejecting the change for Fedora 45 is a statement about readiness, not about destination, in the same way the Fedora 44 power profiles work was a statement about defaults rather than capability.
What to do with this
Nothing urgent, and that is the practical takeaway. Fedora 45 will behave like the Fedora releases before it as far as your CPU is concerned, nothing you run stops being supported, and no fleet needs re-imaging.
Two things are worth noting for planning. If you are still running x86 hardware older than Haswell or Excavator in production, the ecosystem has been moving past you for a while and RHEL 10 has already left, so factor that into your next refresh rather than your next upgrade. And if you build your own packages for a fleet whose hardware you control, the v3 target has always been available to you directly. The hard part Fedora is wrestling with is not the compiler flag, it is shipping two package sets to millions of machines without anybody noticing.
Sources and further reading
- Fedora x86-64-v3 Optimized Packages Pushed Back To At Least Fedora 46, Phoronix, August 18, 2026
- Changes/Build x86-64-v3 Packages, Fedora Project Wiki
- F45 Change Proposal: Build x86-64-v3 Packages, Fedora Discussion
- Fedora Yet To Decide On x86_64-v3 Packages For Fedora Linux 45, via LXer
Frequently asked questions
What exactly is x86-64-v3?
It is one of four micro-architecture feature levels that AMD, Intel, Red Hat and SUSE agreed on so that distributions could talk about CPU capability without listing individual models. Level v1 is the original x86-64 from 2003. Level v3 assumes AVX and AVX2, FMA, BMI and BMI2, MOVBE, XSAVE and a handful of related instructions, which in practice means Intel Haswell and newer, or AMD Excavator and newer. Level v4 adds AVX-512, which is where the hardware picture gets messy again. The point of the levels is that a package can be built once for a capability set rather than for a model list.
What did the Fedora proposal actually ask for?
Not a hard cut. The change, owned by Lleyton Gray, Kyle Gospodnetich and Owen Zimmerman and targeted at Fedora Linux 45, proposed building an additional set of packages at the x86-64-v3 level while keeping the existing x86-64 baseline packages intact, so machines older than Haswell would keep working. Delivery would have been transparent: Release Engineering would publish v3 repositories and images, and DNF5 would pick the v3 packages automatically on systems that support the baseline. The engineering work listed included extending Koji, adding the compiler flags in redhat-rpm-config, the DNF5 selection logic, and Pungi changes for compose generation, tracked in Release Engineering ticket 13310.
Why did FESCo say no?
Two reasons, both procedural rather than philosophical. The committee had been waiting months for performance data solid enough to justify the cost, and it did not consider what it received sufficient. It also wanted a concrete answer on how install media would work in a world where two package sets exist, which is a fair question: an installer image has to boot on the old baseline, then decide what to install, and the compose and image matrix grows. FESCo rejected the change for Fedora 45 but explicitly left the door open for resubmission for Fedora 46 once those gaps are filled.
How much performance is actually on the table?
That is precisely the question the committee found unanswered, and it is worth being honest about it rather than repeating a number nobody has published. The gains from a v3 baseline are real but very uneven: code that vectorises well, or that leans on BMI2 bit manipulation, can move noticeably, while a large share of a distribution is glue, parsers and I/O bound work that will not move at all. Many performance sensitive libraries already ship runtime dispatch, checking CPU features at load time and selecting an optimised path, which means the hottest code often already runs the fast version regardless of the compile baseline. That is exactly why credible measurements across a whole distribution are hard, and why FESCo asked for them.
Does this affect me right now?
Only if you were planning capacity or images around it. Fedora 45 will behave like Fedora 44 on this front, so nothing in your existing deployment changes and no hardware becomes unsupported. If you run RHEL 10 or a rebuild of it, you are already on a v3 baseline, which is also a useful reminder that anything older than Haswell or Excavator has been quietly falling off support matrices for a while. If you build your own packages and you control your hardware fleet, nothing stops you from compiling with the v3 target yourself today, which is the path CachyOS and similar performance oriented distributions took.