This page provides the release criteria for GCC 7.
+ +The GCC team (and, in particular, the Release Managers) will attempt +to meet these criteria before the release of GCC 7.
+ +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 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 Java. +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.
+ +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 is:
+All regressions open in Bugzilla have been analyzed, and all are +deemed as either unlikely to affect most users, or are determined to +have a minimal impact on affected users. For example, a +typographical error in a diagnostic might be relatively common, but +also has minimal impact on users.
+ +In general, regressions where the compiler generates incorrect +code, or refuses to compile a valid program, will be considered to +be sufficiently severe to block the release, unless there are +substantial mitigating factors.
+Our release criteria for the secondary platforms is:
+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 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.
+ +The primary platforms are:
+The secondary platforms are:
+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 as to +merit blocking the release.
+ + +