GettingStarted - GCC Wiki (original) (raw)

Welcome to the Getting Started section of the GCC Wiki

Contents

1. Basics: Contributing to GCC in 10 easy steps
2. Tutorials, HOWTOs
3. Internal documentation
4. Dealing with the source code
5. Structure Of GCC

We are constantly looking for new developers who are willing to donate their time to advance GCC.

This section contains collected information geared towards folks who are new to GCC and may be feeling a bit lost in the barbaric jungles of GCC's source code. Although we are continuously trying to improve GCC's internal modularity and interfaces, the fact remains that GCC is fairly large, has been around for a lot of time and we need to keep it working on the multitude of supported architectures and languages. So, getting to work with GCC can be a challenge.

Everyone is welcome to add links to tutorials, HOWTOs, cheat sheets, etc that may be floating around the net.

Look at EasyHacks for some on-ramp suggestions (but carry on reading this page for how-to information). ImprovementProjects lists more involved projects, that may suit your tastes.

Basics: Contributing to GCC in 10 easy steps

1. Get the sources. The current development tree is accessible using Git
2. Build GCC
   • You do not actually need to install GCC to test it, it is enough to build it, alternatively use the --prefix options of the configure script to install somewhere into your home.
3. Test it and test any changes you make too
   • Unless you have a good reason, you should maximise the number of languages tested by passing --enable-languages=all to configure.
4. Debug any issues you find
5. Format your code for GCC
6. Join the community: Join at least the gcc@ and gcc-patches@ mailing lists.
7. Submit your patches: Produce a patch with git format-patch, produce a Changelog with contrib/mklog, submit patches to the gcc-patches@ mailing list (possibly CC other relevant mailing lists or MAINTAINERS)
8. Decide whether you want to assign your copyright to the FSF or not, in which case you'll have to certify the Developer Certificate of Origin. Both options are easy and described in this page about Contributing to GCC.
9. Commit your patches. For the few first patches you should ask in the submission email that someone commits the patch for you. Once you have a few patches approved, you should ask for write access to the Git repository.
10. Profit!

Tutorials, HOWTOs

• GCC for New Contributors by David Malcolm.
• Building an x86_64-linux-gnux32 (x32) gcc
• Building an x86_64-w64-mingw32 gcc (both native and cross)
• Essential Abstractions in GCC (CGO 2011, Dr. Uday Khedker, Department of Computer Science & Eng IIT Bombay)
• GCC Compile Farm Lightning talk at GHM July 2010
• A blog about GCC development (from 2011, archived)
• Whitepaper about developing a GCC front-end (from 2011, archived)
• Overview of GCC for users, Toulibre Dec 2010
• gcc internals podcast (Introduction)
• Updated GCC Internals Tutorial (November 2007)
• GCC Optimization Course and Tutorial
• GCC Internals Tutorial at CGO 2007
• Workshop on GCC Internals (Advanced GCC Workshop 2007)
• Cheatsheet for loop optimizer (GCC summit 2007)
• GCC Summit Proceedings
• GCC Resource Center (GRC).
• Dwarf2 Exception Handler HOWTO Also known as the "EH newbies HOWTO".
• How to Convert Basic asm to Extended asm.
• Quickstart Guide to Hacking Gfortran

Internal documentation

• GCC internals
• CPP internals
•  [BROKEN] GCC Middle End and Back End API reference (automatically generated with doxygen every week)
• Overview with Examples on the GENERIC Tree API
• BuildInfrastructure: GNU Autoconf

Dealing with the source code

• Formatting code for GCC
• Debugging GCC
• Testing GCC
• Compile time and memory utilization testing
• Writing a new pass
• Writing a new front-end
• Writing a new back end

Structure Of GCC

• Structure of GCC
• Language front ends
• Target independent code transformation frameworks
• Tree Optimizers
• RTL Optimizers
• Target dependent passes and code generation
• reload

Reporting and correcting bugs

When using Bugzilla, GCC maintainers (those having at least write after approval status to GCC trunk) should preferably use their username@gcc.gnu.org account to log in Bugzilla.