About

• Version: 1.2

• Creation date: 2019-12-16

• One line description: Criteria for acceptance of GNU tool chain modifications

• Author(s): Tariq Kurd, Huawei; Jeremy Bennett, Embecosm

Background

Various task groups commission work to add GNU tool chain support for extensions and features. This document provides a baseline set of sign-off criteria. It also serves as a framework for other software projects requiring sign-off criteria.

Components affected are GNU assembler (GAS), GNU linker, GNU binutils, GNU CGEN, GNU Compiler Collection (GCC), libgcc (emulation library), newlib/GlibC and the GNU debugger (GDB). Not all of these are necessarily affected. Typically only C/C++ support is considered, but for some projects, support for other languages may be appropriate.

Details

1. All contributors must have FSF copyright assignment agreements in place. All code must have been transferred to the FSF, which is achieved by adding FSF copyright declarations at the top of all source files.

2. The project should have added regression tests in the following categories where relevant.

   1. GNU assembler target specific regression tests of all new instructions, including tests expected to fail, testing boundary and median cases

   2. GNU assembler target specific regression tests of -march flag extensions, both to verify that new instructions are available when the flag(s) is/are set and that they are not available when not set

   3. GNU linker target specific regression tests of any new relocations added.

   4. GNU compiler target specific tests of all new builtins, intrinsic functions and preprocessor defines.

   5. GNU compiler C/C++ target specific regression tests of -march flag extensions, both to verify that new builtins/intrinsics/preprocessor defines are available when the flag(s) is/are set and that they are not available when not set

   6. GNU compiler C/C++ target specific regression tests of libgcc and newlib multilibs (these tests may belong here, or in the libraries)

   7. GDB target specific regression tests of new features, such as register display, disassembly and XML target feature transfer.

3. Provide test results, which should demonstrate no new failures or unresolved tests compared to the upstream compiler. Total new successes (passes or expected failures) should match the number added above. Results should be identical for Spike and QEMU. Note: This may require extending Spike and/or QEMU.  Depending on the specific work, the following are typically required.

   1. GAS regression tests

   2. GNU linker regression test results

   3. GCC C/C++ regression test result

   4. GDB regression test results

4. RISC-V architectural compliance tests (ACT) for underlying architecture should pass (i.e. we haven’t done anything to break base architectures)

5. Agreed benchmark results should be presented. The choice of benchmark will depend on the specific project. For example Embench may be appropriate for a project targeting small integer RV32 machines, but not for a project targeting large multicore RV32G machines. General projects may require multiple sets of benchmarks.

6. Upstream maintainer reviews and approves the patches. Note: There are different maintainers for different tools, so more than one approver may be needed.

7. The project must be signed off by the Toolchain & Runtimes SSC, who have responsibility for coordination with other projects and can defer that sign-off and responsibility to appropriate subcommittees.

Version History