GCC 14 Release Criteria

This page provides the release criteria for GCC 14.

The GCC team (and, in particular, the Release Managers) will attempt to meet these criteria before the release of GCC 14.

In all cases, these criteria represent the minimum functionality required in order to make the release. If this level of minimum functionality is not provided by a release candidate, then that candidate will probably not become the eventual release. However, a release candidate that does meet these criteria may not necessarily become the official release; there may be other unforeseen issues that prevent the release. For example, if support for the Intel Pentium II is required by the release criteria, it is nevertheless unlikely that GCC would be released even though it did not support the Intel Pentium.

Because the development of GCC is largely dependent on volunteers, the Release Managers and/or Steering Committee may eventually have to decide whether to make a release, even if the criteria here are not met. For example, if no volunteer can be found to verify correct operation of a particular application program on a particular system, then that criterion may be abandoned.


GCC supports several programming languages, including Ada, C, C++, Fortran, Objective-C, Objective-C++, Go, and D. For the purposes of making releases, however, we will consider primarily C and C++, as those are the languages used by the vast majority of users. Therefore, if below the criteria indicate, for example, that there should be no DejaGNU regressions on a particular platform, that criteria should be read as applying only to DejaGNU regressions within the C, C++, and C++ runtime library testsuites.

Primary and Secondary Platforms

GCC targets a vast number of platforms. We have classified these platforms into three categories: primary, secondary, and tertiary. Primary platforms are popular systems, both in the sense that there are many such systems in existence and in the sense that GCC is used frequently on those systems. Secondary platforms are also popular systems, but are either somewhat less popular than the primary systems, or are considered duplicative from a testing perspective. All platforms that are neither primary nor secondary are tertiary platforms.

Our release criteria for primary platforms are:

Our release criteria for the secondary platforms are:

There are no release criteria for tertiary platforms.

In general bugs blocking the release are marked with priority P1 (Maintaining the GCC Bugzilla database).

In contrast to previous releases, we have removed all mention of explicit application testing. It is our experience that, with the resources available, it is very difficult to methodically carry out such testing. However, we expect that interested users will submit bug reports for problems encountered while building and using popular packages. Therefore, we do not intend the elimination of application testing from our criteria to imply that we will not pay attention to application testing.

Primary Platform List

The primary platforms are:

Secondary Platform List

The secondary platforms are:

Code Quality and Compilation Time

In addition to correctness issues (e.g., generating incorrect code, or issuing an invalid diagnostic, or refusing to compile valid code), we will also consider code quality (i.e., the speed with which the generated code executes) and compilation time (i.e., the speed with which the compiler executes).

It is difficult, if not impossible, to set out specific criteria for determining what level of regression is acceptable for these issues. In contrast to most correctness issues, where nothing short of correct is acceptable, it is reasonable to trade off behavior for code quality and compilation time. For example, it may be acceptable, when compiling with optimization, if the compiler is slower, but generates superior code. It may also be acceptable for the compiler to generate inferior code on some test cases if it generates substantially superior code on other test cases. Therefore, the Release Manager, or parties to whom he or she delegates responsibility, will make determinations on a case-by-case basis as to whether or not a code quality or compilation time regression is sufficiently severe to merit blocking the release.