GNU Compiler Collection

From Seo Wiki - Search Engine Optimization and Programming Languages
Jump to navigationJump to search

The GNU Compiler Collection (usually shortened to GCC) is a compiler system produced by the GNU Project supporting various programming languages. GCC is a key component of the GNU toolchain. As well as being the official compiler of the GNU operating system, GCC has been adopted as the standard compiler by most other modern Unix-like computer operating systems, including GNU/Linux, the BSD family and Mac OS X. GCC has been ported to a wide variety of processor architectures, and is widely deployed as a tool in commercial, proprietary and closed source software development environments. GCC is also available for most embedded platforms, for example Symbian,[1] AMCC and Freescale Power Architecture-based chips.[2] The compiler can target a wide variety of platforms, including videogame consoles such as the PlayStation 2[3] and Dreamcast.[4] Several companies[5] make a business out of supplying and supporting gcc ports to various platforms, and chip manufacturers today consider a GCC port almost essential to the success of an architecture.

Originally named the GNU C Compiler, because it only handled the C programming language, GCC 1.0 was released in 1987, and the compiler was extended to compile C++ in December of that year.[6] Front ends were later developed for Fortran, Pascal, Objective-C, Java, and Ada, among others.[7]

The Free Software Foundation (FSF) distributes GCC under the GNU General Public License (GNU GPL). GCC is widely considered a strong example of free software.

History

Richard Stallman started GCC in 1985. He extended an existing compiler to compile C. The compiler originally compiled Pastel, an extended, nonportable dialect of Pascal, and was written in Pastel. It was rewritten in C by Len Tower and Stallman,[8] and released in 1987[9] as the compiler for the GNU Project, in order to have a compiler available that was free software. Its development was supervised by the Free Software Foundation.[10]

By 1991, GCC 1.x had reached a point of stability, but architectural limitations prevented many desired improvements, so the Free Software Foundation (FSF) started work on GCC 2.x.

As GCC was free software, programmers wanting to work in other directions—particularly those writing interfaces for languages other than C—were free to develop their own fork of the compiler. Multiple forks proved inefficient and unwieldy, however, and the difficulty in getting work accepted by the official GCC project was greatly frustrating for many. The FSF kept such close control on what was added to the official version of GCC 2.x that GCC was used as one example of the "cathedral" development model in Eric S. Raymond's essay The Cathedral and the Bazaar.

With the release of 4.4BSD in 1994, GCC became the default compiler for BSD systems.

EGCS fork

In 1997, a group of developers formed EGCS (Experimental/Enhanced GNU Compiler System),[11] to merge several experimental forks into a single project. The basis of the merger was a GCC development snapshot taken between the 2.7 and 2.81 releases. Projects merged included g77 (Fortran), PGCC (Pentium-optimized GCC), many C++ improvements, and many new architectures and operating system variants.[12][13]

EGCS development proved considerably more vigorous than GCC development, so much so that the FSF officially halted development on their GCC 2.x compiler, "blessed" EGCS as the official version of GCC and appointed the EGCS project as the GCC maintainers in April 1999. Furthermore, the project explicitly adopted the "bazaar" model over the "cathedral" model. With the release of GCC 2.95 in July 1999, the two projects were once again united.

GCC is now maintained by a varied group of programmers from around the world. It has been ported to more kinds of processors and operating systems than any other compiler.[14]

Uses

GCC is often the compiler of choice for developing software that is required to execute on a wide variety of hardware and/or operating systems. System-specific compilers provided by hardware or OS vendors can differ substantially, complicating both the software's source code and the scripts which invoke the compiler to build it. With GCC, most of the compiler is the same on every platform, so only code which explicitly uses platform-specific features must be rewritten for each system.

Languages

The standard compiler release 4.3 includes front ends for C (gcc), C++ (g++), Java (gcj), Ada (GNAT), Objective-C (gobjc), Objective-C++ (gobjc++), and Fortran (gfortran). Also available, but not in standard are Modula-2, Modula-3, Pascal (gpc), PL/I, D (gdc), Mercury, VHDL (ghdl).[15] A popular parallel language extension, OpenMP, is also supported. The GCC steering committee has recently announced that it will also support the Go programming language in GCC 4.5 or later.[16]

The Fortran front end was g77 before version 4.0, which only supports Fortran 77. In newer versions, g77 is dropped in favor of the new GFortran front end that supports Fortran 95 and parts of Fortran 2003.[17] A front-end for CHILL was dropped due to a lack of maintenance.

A few experimental branches exist to support additional languages, such as the GCC UPC compiler[18] for Unified Parallel C.

Architectures

GCC target processor families as of version 4.3 include:

Lesser-known target processors supported in the standard release have included:

Additional processors have been supported by GCC versions maintained separately from the FSF version:

When retargeting GCC to a new platform, bootstrapping is often used.

Structure

GCC's external interface is generally standard for a UNIX compiler. Users invoke a driver program named gcc, which interprets command arguments, decides which language compilers to use for each input file, runs the assembler on their output, and then possibly runs the linker to produce a complete executable binary.

Each of the language compilers is a separate program that inputs source code and outputs assembly code. All have a common internal structure. A per-language front end parses the source code in that language and produces an abstract syntax tree ("tree" for short).

These are if necessary converted to the middle-end's input representation, called GENERIC form; the middle-end then gradually transforms the program towards its final form. Compiler optimizations and static code analysis techniques (such as FORTIFY_SOURCE,[20] a compiler directive which attempts to discover some buffer overflows) are applied to the code. These work on multiple representation, mostly the architecture-independent GIMPLE representation and the architecture-dependent RTL representation. Finally, assembly language is produced using architecture-specific pattern matching originally based on an algorithm of Jack Davidson and Chris Fraser.

GCC is written primarily in C except for parts of the Ada front end. The distribution includes the standard libraries for Ada, C++, and Java whose code is mostly written in those languages.[21]

Front-ends

Frontends vary internally, having to produce trees that can be handled by the backend. Currently, the parsers are all hand-coded recursive descent parsers, though there is no reason why a parser generator could not be used for new front-ends in the future (version 2 of the C compiler used a bison based grammar).

Until recently, the tree representation of the program was not fully independent of the processor being targeted.

The meaning of a tree was somewhat different for different language front-ends, and front-ends could provide their own tree codes. This was simplified with the introduction of GENERIC and GIMPLE, two new forms of language-independent trees that were introduced with the advent of GCC 4.0. GENERIC is more complex, based on the GCC 3.x Java front-end's intermediate representation. GIMPLE is a simplified GENERIC, in which various constructs are lowered to multiple GIMPLE instructions. The C, C++ and Java front ends produce GENERIC directly in the front end. Other front ends instead have different intermediate representations after parsing and convert these to GENERIC.

In either case, the so-called "gimplifier" then lowers this more complex form into the simpler SSA-based GIMPLE form which is the common language for a large number of new powerful language- and architecture-independent global (function scope) optimizations.

GENERIC and GIMPLE

GENERIC is an intermediate representation language used as a "middle-end" while compiling source code into executable binaries. A subset, called GIMPLE, is targeted by all the front-ends of GCC.

The middle-end of GCC, starting with the GENERIC representation and ending after the expansion to Register Transfer Language, contains all the optimisers and analysers working independently of the compiled language and independently of the target architecture. The GENERIC representation contains only the subset of the imperative programming constructs optimised by the middle-end.

In transforming the source code to GIMPLE, complex expressions are split into a three address code using temporary variables. This representation was inspired by the SIMPLE representation proposed in the McCAT compiler[22] by Laurie J. Hendren[23] for simplifying the analysis and optimisation of imperative programs.

Optimization

Optimization can occur during any phase of compilation, however the bulk of optimizations are performed after the syntax and semantic analysis of the front-end and before the code generation of the back-end, thus a common, even though somewhat contradictory, name for this part of the compiler is "middle end."

The exact set of GCC optimizations varies from release to release as it develops, but includes the standard algorithms, such as loop optimization, jump threading, common subexpression elimination, instruction scheduling, and so forth. The RTL optimizations are of less importance with the addition of global SSA-based optimizations on GIMPLE trees,[24] as RTL optimizations have a much more limited scope, and have less high-level information.

Some of these optimizations performed at this level include dead code elimination, partial redundancy elimination, global value numbering, sparse conditional constant propagation, and scalar replacement of aggregates. Array dependence based optimizations such as automatic vectorization and automatic parallelization are also performed. Profile-guided optimization is also possible as demonstrated here: http://gcc.gnu.org/install/build.html#TOC4

Back-end

The behavior of GCC's back end is partly specified by preprocessor macros and functions specific to a target architecture, for instance to define the endianness, word size, and calling conventions. The front part of the back end uses these to help decide RTL generation, so although GCC's RTL is nominally processor-independent, the initial sequence of abstract instructions is already adapted to the target. At any moment, the actual RTL instructions forming the program representation have to comply with the machine description of the target architecture.

Towards the end of compilation, valid RTL is further reduced to a strict form in which each instruction refers to real machine registers and real instructions from the target's instruction set. Forming strict RTL is a very complicated task, done mostly by the register allocation first but completed only by a separate "reloading" phase which must account for the vagaries of all of GCC's targets.

The final phase is somewhat anticlimactic, because the patterns to match were generally chosen during reloading, and so the assembly code is simply built by running substitutions of registers and addresses into the strings specifying the instructions.

Debugging GCC programs

The primary tool used to debug GCC code is the GNU Debugger (gdb). Among more specialized tools are Valgrind, for finding memory errors and leaks, and the graph profiler (gprof) which can determine how much time is spent in which routines, and how often they are called; this requires programs to be compiled with profiling options.

Possible future alternatives

GCC has received criticism from OpenBSD developers such as Theo de Raadt and Otto Moerbeek. Although they continue to use GCC as the only compiler for their software distribution, they complain that it is large, buggy, slow, and generates poor code,[25] and also dislike v3 of the GNU GPL.[26] The OpenBSD project has made various efforts to replace GCC with the Portable C Compiler[26]. Meanwhile, the FreeBSD project is investigating the possibility of replacing GCC with Clang/LLVM.[27].

See also

References

  1. "Symbian GCC Improvement Project". http://www.inf.u-szeged.hu/symbian-gcc/. Retrieved 2007-11-08. 
  2. "Linux Board Support Packages". http://www.freescale.com/webapp/sps/site/overview.jsp?code=CW_BSP&fsrch=1. Retrieved 2008-08-07. 
  3. "setting up gcc as a cross-compiler". ps2stuff. 2002-06-08. http://ps2stuff.playstation2-linux.com/gcc_build.html. Retrieved 2008-12-12. 
  4. "sh4 g++ guide". Archived from the original on 2002-12-20. http://web.archive.org/web/20021220025554/http://www.ngine.de/gccguide.html. Retrieved 2008-12-12. "This guide is intended for people who want to compile C++ code for their Dreamcast systems" 
  5. "FSF Service Directory". http://www.fsf.org/resources/service. 
  6. Cite error: Invalid <ref> tag; no text was provided for refs named release-history
  7. "Programming Languages Supported by GCC". GNU Project. http://gcc.gnu.org/onlinedocs/gcc-4.4.0/gcc/G_002b_002b-and-GCC.html#G_002b_002b-and-GCC. Retrieved 2009-05-03. 
  8. Stallman, Richard M. (February 1986). "GNU Status". GNU's Bulletin (Free Software Foundation) 1 (1). http://web.cecs.pdx.edu/~trent/gnu/bull/01/bull01.txt. Retrieved 2006-09-26. 
  9. Tower, Leonard (1987) "GNU C compiler beta test release," comp.lang.misc USENET newsgroup; see also http://gcc.gnu.org/releases.html#timeline
  10. Stallman, Richard M. (2001) "Contributors to GCC," in Using and Porting the GNU Compiler Collection (GCC) for gcc version 2.95 (Cambridge, Mass.: Free Software Foundation)
  11. "Pentium Compiler FAQ". http://home.schmorp.de/pgcc-faq.html#egcs. 
  12. "A Brief History of GCC". http://gcc.gnu.org/wiki/History. 
  13. "The Short History of GCC development". http://www.softpanorama.org/People/Stallman/history_of_gcc_development.shtml. 
  14. Linux Information Project (LINFO) accessed 2007-03-20
  15. GCC Front Ends, GCC.org, Retrieved May 11, 2008.
  16. "gccgo language contribution accepted", gmane.org, Retrieved January 26, 2010.
  17. "Fortran 2003 Features in GNU Fortran". http://gcc.gnu.org/wiki/Fortran2003. 
  18. "GCC UPC (GCC Unified Parallel C) | intrepid.com". intrepid.com<!. 2006-02-20. http://www.intrepid.com/upc.html. Retrieved 2009-03-11. 
  19. "sx-gcc: port gcc to nec sx vector cpu". http://code.google.com/p/sx-gcc/. 
  20. "Security Features: Compile Time Buffer Checks (FORTIFY_SOURCE)". fedoraproject.org. http://fedoraproject.org/wiki/Security/Features. Retrieved 2009-03-11. 
  21. "languages used to make GCC". http://www.ohloh.net/projects/gcc/analyses/latest. 
  22. McCAT
  23. Laurie J. Hendren
  24. From Source to Binary: The Inner Workings of GCC, by Diego Novillo, Red Hat Magazine, December 2004
  25. "More on OpenBSD's new compiler" (PDF). TheJemReport.com. 2007-10-15. http://www.thejemreport.com/index2.php?option=com_content&id=369&do_pdf=1. Retrieved 2010-01-03. 
  26. 26.0 26.1 Dru Lavigne (2007-09-25). "Towards a BSD-licensed Compiler". It.toolbox.com. http://it.toolbox.com/blogs/bsd-guru/towards-a-bsdlicensed-compiler-19289. Retrieved 2010-01-03. 
  27. "BuildingFreeBSDWithClang". Wiki.freebsd.org. http://wiki.freebsd.org/BuildingFreeBSDWithClang. Retrieved 2010-01-03. 

Further reading

External links