From Open64 Wiki
All developers who have a subversion login for svn.open64.net can check-in new files or modify existing files in the open64.net subversion repository. A list of all developers is available in the "MAINTAINERS" file in the top level open64 directory. This file also contains the list of gatekeepers for the various phases in the compiler.
The following sections outline various aspects of development, testing and checkin of changes by developers:
1. Design / Timing
For significant new changes like adding a new optimziation phase, algorithmic change to an existing component or a major extension, the developer should post a design note to the open64-devel mailing list describing the proposed change. This serves several purposes: a) Informs others that you are working in this area - avoids duplicate work, allows other interested developers to offer to work jointly with you b) Provides an opportunity for others to provide feedback c) Helps the release planning process for Open64 compiler
Significant new check-ins can be made at any time, except close to a release, stage 2. The release manager(s) may restrict check-ins to critical bug fixes only for a short duration before a release.
2. Coding Guidelines
There are no formal coding rules for Open64. Please follow the coding style of the existing code.
Comments in the code describing your change are highly recommended. Please avoid using "fixed bug #1234" type comments.
Please try to avoid adding target-specific #Ifdefs in the code. For example, target specific defaults can be set in Preconfigure_Target in common/com/<target>/config_targ.cxx rather than using #ifdefs in common/com/config.cxx
3. Testing Requirements
The amount and type of testing done before a checkin depends on the where the change is made and how widespread it is. For changes that apply only to a single target, testing can be limited to that target alone. For changes to any common source file, testing needs to be done on your target platform of interest as well as x86/Linux since that is the primary testing platform for Open64. Testing on other platforms is left to the owners/maintainers for those platforms.
For simple changes, the testing requirements are:
a) No compile time failure for x86 build b) Run the gcc regression test suite on x86/Linux with no new failures. There are many tests that fail currently due to missing GCC compatibility features, but we don't want any regressions. As Open64 compiler adds more GCC compatibility features, the number of expected failures for gcc regression suite should reduce. c) For changes that may impact performance, run the SPEC2006 test suite at -Ofast to ensure there is no performance regression.
For a major change (e.g. AMD's merge corresponding to their 4.2.2 releaes), the changes should be made on a branch and access provided to other developers at least 2 weeks prior to checkin. The additional testing requirements are:
a) Successful bootstrap of Open64 compiler on x86/Linux. If your platform of interest is different than x86/Linux, ensure a successful bootstrap on that platform as well. b) Pass SPEC2006 int and fp test suites at -O1, -O2 and -Ofast. Very few performance regressions should be present compared to the Open64 compiler before your change. c) No regression in language test suites for C, C++ and Fortran (Plumhall, Perennial, Modena, Fortran: ABI, GSA, CRI, Unicomp). d) Ask for volunteers to do testing on other platforms using your branch. Respond to problems discovered in this process.
Recommended additional testing for major changes (and before each release):
a) Pass SPEC2000 int and fp test suites at -O1, -O2 and -Ofast. b) Pass SPEC OMPM2001 and SPEC MPI2007 at -O1, -O2 and -Ofast. Use training input for MPI2007 due to excessive runtime for ref input.
Since the SPEC and Language test suites are not available for free, if you don't have access to these, ask for volunteers who have access to these test suites.
4. Review and Approval Process
All check-ins must be reviewed and approved by at least one Gatekeeper. The patch for the upcoming change needs to be mailed out to the open64-devel mailing list at least 2 days before the check-in to allow everyone a chance to provide feedback. On the request for approval, developers need to make it easier for gate-keepers to identify the requests that are intended for them, by including in their email subject line the ‘component name’ when requesting code/patch review.
The checkin message should contain the following: a) A brief description of the change. b) If the change fixes a bug from the bugs.open64.net Bugzilla database, please add "Fix for bug#xxxx" in the checkin message. c) The name of the Gatekeeper who approved the checkin. d) If change has been copied from some other place, indicate the origin of the source code and provide confirmation that the license is compatible with Open64.
5. Copyright Notice and Licensing
Any new source file checked into the Open64 source tree should have a GPL v2+ (GPL version 2 or later) compatible license. The following link provides a template for the header of new source files in Open64:
For changes to existing source files, do not change the License notice. You may add a Copyright Notice to the header of the file for your contribution using the following template:
Copyright (C) <year> <Author> All Rights Reserved.
If a source change has been copied from some other place, the contributor is responsible for providing information about the origin of the source code as well as confirming that the license of the code being copied is compatible with Open64.
6. Gatekeeper Policy
Gatekeepers are designated approvers for various components of Open64. They are responsible for design / code review, determine what check-in is allowed, and determine testing criteria for specific check-in. If a patch review is large, Gate Keeper team could sponsor the distribution of request.
In order to avoid redesign, maintainers are advised to gain support from at least a Gatekeeper by sharing the design including design objectives, rationale, important data structure, interfaces and test plan, during the design phase.
Gatekeepers are nominated by the community or individuals volunteer themselves via open64-devel mailing list with the areas of coverage, an articulation of the candidate’s qualification including contributions to Open64 compiler architecture design and/or significant contribution to the code base. OSG reviews the qualification and make the selection decision with majority vote. The list of Gatekeepers and their coverage are posted in open64.net website, and the current list of gatekeepers can be looked up in the "MAINTAINERS" file in the top level source directory.
Based on the knowledge across various part of the Open64 functionalities Gatekeepers are classified as global or local Gatekeeper. The global Gatekeeper oversees every component in the compiler while local Gatekeeper only oversee one or a few components, including Language front ends, WHIRL Generator, Code Generator(CG), Global Optimizer(WOPT), Loop Nest Optmizer(LNO), Inter-Procedural Analysis(IPA), Common Infrastructure, Tools, and so on. Besides the Global or Local Gatekeepers, there are gatekeepers for specific domain such as OpenMP, Feedback based optimization, and so on. They are experts in domain and have knowledge across multiple components.
All gatekeepers are appointed by OSG for a term of one year, and the term can be renewed each year without a limit. The appointment and renewal are based on the ability and willingness of the individual to serve the gatekeeper role and the feedback from the community on individual gatekeeper’s performance. The decision is at a sole discretion of OSG. As in the OSG process, each approval requires majority votes from the voting population. Considering the number of gatekeepers and a smooth operation of review processes, the appointments and renewals of gatekeepers will probably be handled in a staggering manner. The initial plan is to process these at one of the OSG meetings every quarter.
There may be 1 – 3 local Gatekeepers designated for each component and 3 – 5 global Gatekeepers. When there exists difference in opinion on specific check-in, release manager will orchestrate the resolution.
Gatekeepers need to feel the ownership of the compiler architecture and solicit additional Gatekeepers for reviewing big check-in.