GCC Projects

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

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

Improve the installation procedure

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:

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.

The old PROBLEMS file

The following used to be in a file PROBLEMS in the GCC distribution. Probably much of it is no longer relevant as of GCC 3.0 (the file hadn't changed since GCC 2.0), but some might be. Someone should go through it, identifying what is and isn't relevant, adding anything applicable to current GCC (and describing a bug) to our bug-tracking system and sending patches to gcc-patches to remove such analysed entries from the list.

  1. Possible special combination pattern: If the two operands to a comparison die there and both come from insns that are identical except for replacing one operand with the other, throw away those insns. Ok if insns being discarded are known 1 to 1. An andl #1 after a seq is 1 to 1, but how should compiler know that?
  2. Any number of slow zero-extensions in one loop, that have their clr insns moved out of the loop, can share one register if their original life spans are disjoint. But it may be hard to be sure of this since the life span data that regscan produces may be hard to interpret validly or may be incorrect after cse.
  3. In cse, when a bfext insn refers to a register, if the field corresponds to a halfword or a byte and the register is equivalent to a memory location, it would be possible to detect this and replace it with a simple memory reference.

Please send FSF & GNU inquiries & questions to gnu@gnu.org. There are also other ways to contact the FSF.

These pages are maintained by the GCC team.

For questions related to the use of GCC, please consult these web pages and the GCC manuals. If that fails, the gcc-help@gcc.gnu.org mailing list might help.
Please send comments on these web pages and the development of GCC to our developer mailing list at gcc@gnu.org or gcc@gcc.gnu.org. All of our lists have public archives.

Copyright (C) Free Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110, USA.

Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.

Last modified 2006-06-21 Valid XHTML 1.0