• SummerOfCode

Google Summer Of Code

Thanks for your interest in the GNU Compiler Collection as your mentoring organization in Google's Summer of Code (GSoC).

In 2018, GCC has applied independently to be a GSoC mentoring organization. The primary org-admin is Martin Jambor. In the past, GCC has also applied under the umbrella of GNU project mentoring organization.

If you are a student with a project idea or want to work on any of the ideas below, please discuss it as soon as possible (way before the application) via the mailing list or via IRC. For general (non-GCC specific) questions about GSoC, the relevant mailing list is https://lists.gnu.org/mailman/listinfo/summer-of-code

Project Ideas

Selected project ideas (2018)

When discussing GSoC project ideas for 2018 in the community, we have found out we are especially interested in the following few. One of their main advantages, apart from their particular relevance and usefulness this year, is that we already have mentors for them. That does not mean we will not consider other projects, definitely feel free to look also at and we will be also happy to discuss with us ideas of your own. Nevertheless, please do especially consider applying for the following:

• Implementation of OMPD in GCC, libgomp and gdb. Jakub Jelinek would mentor the GCC side (we plan to reach out to the gdb community for a co-mentor).

• Type Sanitizer. Both LLVM and GCC compilers do share a common sanitizer library called libsanitizer. The library has recently received support of typed-based sanitization (TySan). Goal of the task would be to investigate and prototype usage of type-based aliasing rules information provided by GCC in order to detect violations of strict aliasing rules. The project would be mentored by Martin Liska.

• Textual Representation of LTO Object Files. Link-Time Optimization (LTO) is a technique where an intermediate representation of translation units is serialized and loaded during link time. That leads to massive optimization opportunities as a compiler can see the whole program. Current format of LTO object file is binary and we would welcome to have also an equivalent textual representation. The format should be human readable and easily adjustable. Such improvement would help a lot to reproduce and debug complication LTO bugs that require multiple object files to be compiled. The project would also be mentored by Martin Liska.
• Implement a fuzzer leveraging GCC extensions. Fuzzers like csmith are fairly good at finding compiler bugs. But they only generate standard C, but no extensions. gcc has many extensions, which are not covered. It would be good to extend a fuzzer like csmith to fuzz extensions like OpenMP, attributes, vector extensions, etc. Then run the fuzzer and report compiler bugs. The project would be mentored by Andi Kleen.

• GCC supports built-in functions for math.h and complex.h functions in the C99/C11 standards (both folding calls for constant arguments, and expanding inline when the processor supports appropriate functionality). More such functions have been added in ISO/IEC TS 18661, supporting features of IEEE 754-2008. It would be useful to have built-in functions for those, both folding for constant arguments, and expanding inline where appropriate (e.g. for roundeven and the functions rounding result to narrower type, on some processors; roundeven can be inlined on x86 for SSE4.1 and later, and the narrowing functions on IA64 and POWER8, for example). Existing built-in functions would provide a guide for how to do this. This project would be primarily mentored by Joseph Myers (see also the description he posted at https://gcc.gnu.org/ml/gcc/2018-03/msg00001.html).

• GCC plugin API. GCC currently supports plugins but there is not real API to speak of. The project would look at a small number of plugins and define an GCC plugin API that will allow them to function and that will be based on abstract compiler constructs (such as basic block or statement, as opposed to the GCC internal representation of these constructs) as much as practical. While the API will most likely be GCC-specific, the goal is to come up with a basis of an API that will not need to change often in future versions of GCC (and can be guaranteed to be stable across minor versions) and will be easily understandable to people who know general compiler theory but very little of GCC internals. Ideally this same API could be provided by other compilers such as LLVM as well. Unless Martin Jambor finds you a better mentor, he will mentor himself.
• Parallelize the compilation using threads. GCC currently has an awful lot of truly global state and even more per-pass global state which makes this somewhat hard. The idea is to avoid issues with global state as much as possible by partitioning the compilation pipeline in pieces that share as little global state as possible and ensure each thread only works in one of those partitions. The biggest roadblock will be the not thread-safe memory allocator of GCCs garbage collector. The compilation pipeline would in the end be driven by a scheduler assigning functions to be optimized to the partitions in the pipeline. This project would be mentored by Richard Biener.
• Binutils support for AIX 7.2. GNU Binutils (Gas, Gld, etc.) currently support AIX 4.3.3 and partially support AIX 5.1. GNU BFD library has existing support for XCOFF and GDB functions. This project would update AIX support in GNU Binutils support for the latest release of AIX 7.2. The main goal is the ability to bootstrap GCC with GNU Binutils (accept all current GCC instructions, directives and options for AIX Assembler and Linker) and produce correct, functioning GCC executable and GCC runtime shared object libraries (libgcc, libstdc++). This project would be mentored by David Edelsohn.

GCC Improvement Projects

There are several pages with general ideas for GCC, many of which we linked below for easy access. These ideas usually are not just one project but a group of distinct projects.

• Ideas for speeding up GCC

• Improvements to GCC on Windows

• Partial_Transitions

• Improve the regression testing system, for example to detect places where the generated code changed (useful for refactoring).
• Fix -ftrapv so that it works.

• Improve GCC Diagnostics

• Promote C++ operator new to alloca when pointer does not escape and user allows non-conformance to C++ standard

• Improve loop unrolling heuristics and enable loop unrolling with default optimization
• Analyze and improve inlining, loop unrolling, reassociation and predictive commoning heuristics for PowerPC architecture
• Use TARGET_EXPAND_TO_RTL_HOOK for pipelined divide on PowerPC
• Support AIX XCOFF file format for LTO (David Edelsohn)

• GCC Improvement Projects

  • This category of projects deals with a range of changes, from simple to challenging. These projects are of great interest to us, because they address some long-standing architectural issues that we want to fix.

Link-time and interprocedural optimization improvements

Link-time optimization is relatively new infrastructure in GCC and there are many areas how to make it better. (Jan Hubicka, 2015)

• Generate LTO object files directly from GCC (bypassing assembler). Perliminary patch is at https://gcc.gnu.org/ml/gcc/2014-09/msg00340.html. Finishing this would require work on libiberty simple object file handling, in the GCC wrapper and in GCC itsef. If finished, the compile time performance should improve by several percent.

• Implement static code placement pass (function reordering. GCC currently lay down compilation units in the topological order. This is good for optimization, but produce code that execute from the end. With link time optimization it is possible to get a lot better code placement. This would build up on Martin Liska's master thesis. Ask Jan Hubicka for some experimental patches.

• Implement inter-procedural value-range propagation pass. This would be especially useful for deriving loop bounds and optimizing out checks for NULL pointers.
• Implement auto-detection of additional function and variable attributes. GCC currently auto-detect pure, const and nothrow. Many other attributes can be supported
• Work on general scalability and reliability improvements. This would involve testing LTO on new applications (current LTO is tested mostly on GCC itself, Firefox, Libreoffice, Linux kernel and Chromium).
• Implement tree level section anchors to improve code generation at ARM/PPC.

New optimization passes

• Implement code motion of stores towards entry (and use this to improve code for int to float conversion on rs6000-based targets)
• Implement a prototype for early instruction selection
• Propagate interprocedural dataflow from GIMPLE to RTL
• Add Factored Use-Def (FUD) chains to RTL

• Loop optimizations and automatic parallelization based on Graphite (Graphite Summer of Code ideas)

• Implement a basic-block local scheduling pass to improve SSA name coalescing opportunities at RTL expansion time

• Implement a (prototype) addressing mode selection (AMS) pass as a replacement of auto-inc-dec. For more details see PR 56590.

Language front-ends and run-time libraries

• C++11 Support in GCC and libstdc++

• gcj, libgcj, and GNU Classpath ideas

• libstdc++ todo (Broken Link!)

• libstdc++ ideas

• Refactor libstdc++ for optional smaller footprint configuration, e.g., iostreams without templates

• Fortran front end:

  • Extend OOP support (possible mentors: Janus Weil, Tobias Burnus) by adding missing features, such as:

    • Finalization

    • Associate construct

  • coarray support for SMP and distributed memory systems (possible mentor: Tobias Burnus)

    • Coarrays are a PGAS extension, which is part of Fortran 2008.

    • Possible task: Improving the multi-image support, which uses OpenCoarray communication library

    • Implement Fortran 2015 additions (TS18508) additions
  • Run-time argument checking: Uninitialized variables, correctness of arguments
  • Better IEEE support

  • Other Unimplemented Fortran 2003, Fortran 2008 features, TS 29113 features

  • Asynchronous IO support. Currently F2003 asynchronous IO syntax is supported, but all IO is done synchronously.
  • IO optimization. Currently formatted scalar IO is quite slow and uses lots of stack space.
  • F2003 intrinsics support. As of F2003 many intrinsics must support arbitrary kinds.

• OpenMP 4.0 runtime improvements: openmp

• GCC Go escape analysis: in Go, taking the address of something means that it lives on the heap--Go has no such thing as a dangling pointer. It is possible to use escape analysis to determine whether the pointer ever escapes its scope. If it does not, then the object whose address is taken can be allocated on the stack rather than the heap, which is more efficient. A particular example is calls to functions like fmt.Printf, which allocate a slice of the arguments passed in. Escape analysis can allocate that slice on the stack rather than the heap.

Improving GCC Developer Documentation

Other projects

• Converting different program representation levels of GCC back to the source code. It's not a trivial task but I saw substantial interest to that recently.

• GCC projects page

• Separate the frontends from the middle-end (near bottom of page)

• Diagnostics XML output for IDEs (there is a prototype available).

• Replace libiberty with gnulib. See http://gcc.gnu.org/ml/gcc-patches/2012-08/msg00362.html Initial work was done in SoC 2016 (replacelibibertywithgnulib).

• Finish the implementation of a stable introspection plugin API (with the possibility of extending it to cover non-introspection cases)

• Record all GCC optimization decisions and related code "features" at different levels (function, loop, block enumeration) to expose and analyze all internal optimization decisions. Suggestion to use extensible JSON as in Collective Mind framework (c-mind.org). -- G. Fursin, 2014.
• Modify any GCC optimization decisions externally through plugins (see MILEPOST GCC, for example). -- G. Fursin, 2014.
• Systematize learning of optimal optimization decisions for multiple benchmarks, data sets and architectures (see c-mind.org/repo, for example). -- G. Fursin, 2014.
• Extend GCC plugin framework to enable code instrumentation (insert calls to external function after individual instructions) for dynamic code analysis. We need it to extend our TM/TLS models. -- G. Fursin, 2014.

If you are interested in learning your way around the GCC codebase, the Partial_Transitions is a good place to start.

Other project ideas can be found in the bug database. Look for old bugs which are still open.

Or invent your own project. We're always open to good ideas. But note that we are probably not too interested in projects to add new extensions to the C or C++ languages. We've found over time that these tend to introduce more problems than they solve.

Thanks, and we look forward to your submissions!

Before you apply

...and perhaps before you even reach out to us on the mailing list, make sure you can check out the GCC trunk source code, can build GCC from it, run the testsuite, save results from a testsuite run, build and run the testsuite and compare the results of the two runs (this is something that would need doing very many times in the course of any project working on GCC).

The following links should help you:

• How to check out our sources using svn and git is described at https://gcc.gnu.org/svn.html and https://gcc.gnu.org/wiki/GitMirror respectively.

• Steps linked from https://gcc.gnu.org/install/ show you how to configure, build and test GCC is described in (look for --disable-bootstrap, among other things).

• Make sure you also look at Installing GCC and Getting Started wiki pages.

And while you are at it, also have a look at the source. But if you have done all of the above and still find it a little bit intimidating or if you have difficulties figuring out where to start looking for particular things, do not despair. That is something the mentors and the community at large are willing to help you with.

Application

Students applying for a GCC Google Summer of Code project need to have experience coding in C/C++ and should have at least some theoretical background in the area of compilers and compiler optimizations.

First, you need to select a project. If you have been following GCC development, you might have an idea of your own, otherwise look into the idea section above and try to pick an idea there. In the course of selecting a project, do not hesitate to ask questions or request more details from the community by email to the gcc@gcc.gnu.org mailing list with the string "GSoC" in the email subject or on our #gcc IRC channel at irc.oftc.net. Please note that the mailing list does not accept HTML messages, you must set your email client to plain text. We also encourage you to browse through our web site at https://gcc.gnu.org/ and of course this wiki.

After you believe you have selected and/or refined the project idea, please make sure you send us an email about your intention to apply to the gcc@gcc.gnu.org mailing list with the string "GSoC" in the email subject, in addition to any general required steps to apply to the GSoC program.

Last but not least, the GCC is owned by the Free Software Foundation (FSF), as such, all contributors must assign their copyright to the FSF before any of their changes are accepted. The copyright assignment process is described on pages:

• http://gcc.gnu.org/contribute.html#legal and

• https://gcc.gnu.org/wiki/GettingStarted

Further tips and guidelines

• A gcc Summer of Code participant for 2006, Laurynas Biveinis, wrote a blog about it.

• Another former GCC Summer of Code student has written an excellent page reporting important advice for students : 5 advice to get your Google Summer of Code proposal accepted.

• The Drupal project has a great page on How to write an SOC application.

• Provide a plan and a time-line with your proposal. A proposal without this is probably overestimating or underestimating the effort.
• Provide clearly defined goals in your proposal. Vague proposals give the impression that the student does not actually know sufficient about the topic to spend time efficiently.
• Be honest and realistic. We prefer a smaller project with clearly defined goals to a far-reaching but vague proposal (that is likely never going to be finished by the student).
• Students that have already submitted good patches give a much better impression to reviewers and potential mentors.

• Starting with some small patch for the area you are interested in before the proposal submittal period can help (ask for guidance and a simple enough project): It helps you to get the code known and to decide whether you really want to do the project, it shows how the development procedure is, and helps potential mentors to judge the proposal based on actual work. Besides: Also small fixes are good and getting people known by email (or IRC) exchange is nice by itself

• Ad let's stress again that you need to present your project in the mailing list gcc@gcc.gnu.org (or, if applicable, at fortran@gcc.gnu.org or java@gcc.gnu.org ) to be sure it is a good idea. Add "GSoC" to the subject.

Accepted GCC Projects

2016

2015

2014

2013

2012

2011

2010

The source code for finished projects can be found at Google's code hosting site and their respective SVN branches.

2009

2008

2007

2006