GCC Projects

This is an incomplete list of things you could work on if you want to help develop GCC:

• If you are new to GCC, start with our list of projects for beginner GCC hackers.
• Investigate bugs and attempt to fix bugs in our bug tracker, see whether they still are present in current GCC.
• Projects for the GCC web pages.
• Projects for improving the GCC documentation.
• There are several development branches with projects that you may be able to help out with.
• Investigate and fix some of the known optimizer inadequacies.
• Projects for the C preprocessor.
• Projects for improving the C front end.
• Implementing new C++14 features.
• The GNU UPC Project.
• Improve the installation procedure
• Simpler porting
• Generalize the machine model

Remember to keep other developers informed of any substantial projects you intend to work on.

Improve the installation procedure

• See a message from Zack Weinberg, and follow-ups to it, for some discussion of some of these ideas.
• Move the installation from incomprehensible shell scripts in the Makefiles to more comprehensible shell scripts outside the Makefiles.
• When installing as root, make the installed headers in $(libsubdir) be owned by root rather than the user who did the build.
• Be consistent about what programs get links such as i686-pc-linux-gnu-gcc and i686-pc-linux-gnu-gcc-3.4.1. Any program embedding architecture or version dependencies may need such links.
• Add a configure option --enable-cc-links or similar which causes links to the compiler driver or shell scripts to be installed under names cc (the traditional Unix compiler name and a legacy utility in Unix98, accepting an unspecified C language variant), c89 (POSIX; a script running gcc -std=c89 -pedantic) and c99 (the Austin Group revision of POSIX; a script running gcc -std=c99 -pedantic) for systems such as GNU/Linux where GCC is the system compiler.
• Fix the issues discussed in PR other/346.

Simpler porting

Right now, describing the target machine's instructions is done cleanly, but describing its addressing mode is done with several ad-hoc macro definitions. Porting would be much easier if there were an RTL description for addressing modes like that for instructions. Tools analogous to genflags and genrecog would generate macros from this description.

There would be one pattern in the address-description file for each kind of addressing, and this pattern would have:

• the RTL expression for the address
• C code to verify its validity (since that may depend on the exact data).
• C code to print the address in assembly language.
• C code to convert the address into a valid one, if it is not valid. (This would replace LEGITIMIZE_ADDRESS).
• Register constraints for all indeterminates that appear in the RTL expression.

Generalize the machine model

Some new compiler features may be needed to do a good job on machines where static data needs to be addressed using base registers.

Some machines have two stacks in different areas of memory, one used for scalars and another for large objects. The compiler does not now have a way to understand this.