Basic compilation of a C language program using GCC is easy. Start with the following simple program:

#include <stdio.h>

int main ()
{
  printf ("Hello world!\n");
  return 0;
}

The following procedure illustrates the compilation process for C in its most basic form.

Basic compilation of a C++ language program using GCC is similar. Start with the following simple program:

#include <iostream>

using namespace std;

int main(void)
{
  cout << "Hello World!" << endl;
  return 0;
}

The following procedure illustrates the compilation process for C++ in its most basic form.

To use basic compilation involving multiple files or object files, start with the following two source files:

#include <stdio.h>
void hello()
{
  printf("Hello world!\n");
}

extern void hello();

int main()
{
  hello();
  return 0;
}

The following procedure illustrates a simple, multi-file compilation process in its most basic form.

Different projects require different optimization options. There is no one-size-fits-all approach when it comes to optimization, but here are a few guidelines to keep in mind.

The option -mtune= optimizes instruction scheduling to fit your architecture by tuning everything except the ABI and the available instruction set. This option will not chose particular instructions, but instead will tune your program in such a way that executing on a particular architecture will be optimized. For example, if an Intel Core2 CPU will predominantly be used, choose -march=core2. If the wrong choice is made, the program will still run, but not optimally on the given architecture. The architecture on which the program will most likely run should always be chosen.

The option -march= optimizes instruction selection. As such, it is important to choose correctly as choosing incorrectly will cause your program to fail. This option selects the instruction set used when generating code. For example, if the program will be run on an AMD K8 core based CPU, choose -march=k8. Specifying the architecture with this option will imply -mtune=.

The -mtune= and -march= commands should only be used for tuning and selecting instructions within a given architecture, not to generate code for a different architecture (also known as cross-compiling). For example, this is not to be used to generate PowerPC code from an Intel 64 and AMD64 platform.

For a complete list of the available options for both -march= and -mtune=, refer to the GCC documention available here: GCC 4.4.4 Manual: Hardware Models and Configurations

When code size is not an issue, -O3 is preferrable. This option produces code that is slightly larger but runs faster because of a more frequent inline of functions. This is ideal for floating point intensive code.

The other general purpose optimization flag is -Os. This flag also optimizes for size, and produces faster code in situations where a smaller footprint will increase code locality, thereby reducing cache misses.

Use -frecord-gcc-switches when compiling objects. This records the options used to build objects into objects themselves. After an object is built, it determines which set of options were used to build it. The set of options are then recorded in a section called .GCC.command.line within the object and can be examined with the following:

$ gcc -frecord-gcc-switches -O3 -Wall hello.c -o hello
$ readelf --string-dump=.GCC.command.line hello

String dump of section '.GCC.command.line':
  [     0]  hello.c
  [     8]  -mtune=generic
  [    17]  -O3
  [    1b]  -Wall
  [    21]  -frecord-gcc-switches

It is very important to test and try different options with a representative data set. Often, different modules or objects can be compiled with different optimization flags in order to produce optimal results. Refer to Section 4.1.6.5, “Using Profile Feedback to Tune Optimization Heuristics.” for additional optimization tuning.

During the transformation of a typical set of source code into an executable, tens of hundreds of choices must be made about the importance of speed in one part of code over another, or code size as opposed to code speed. By default, these choices are made by the compiler using reasonable heuristics, tuned over time to produce the optimum runtime performance. However, GCC also has a way to teach the compiler to optimize executables for a specific machine in a specific production environment. This feature is called profile feedback.

Profile feedback is used to tune optimizations such as:

Profile feedback compiles a program first to generate a program that is run and analyzed and then a second time to optimize with the gathered data.

Step three will use the profile information gathered in step one to tune the compiler's heuristics while optimizing the code into a final executable.

Multiple data collection runs, as seen in step two, will accumulate data into the profiling file instead of replacing it. This allows the executable in step two to be run multiple times with additional representative data in order to collect even more information.

The executable must run with representative levels of both the machine being used and a respective data set large enough for the input needed. This ensures optimal results are achieved.

By default, GCC will generate the profile data into the directory where step one was performed. To generate this information elsewhere, compile with -fprofile-dir=DIR where DIR is the preferred output directory.

On a 64-bit host, GCC will build executables that can only run on 64-bit hosts. However, GCC can be used to build executables that will run both on 64-bit hosts and on 32-bit hosts.

To build 32-bit binaries on a 64-bit host, first install 32-bit versions of any supporting libraries the executable may need. This must at least include supporting libraries for glibc and libgcc, and possibly for libstdc++ if the program is a C++ program. On Intel 64 and AMD64, this can be done with:

yum install glibc-devel.i686 libgcc.i686 libstdc++-devel.i686

There may be cases where it is useful to to install additional 32-bit libraries that a program may need. For example, if a program uses the db4-devel libraries to build, the 32-bit version of these libraries can be installed with:

yum install db4-devel.i686

After the 32-bit libraries have been installed, the -m32 option can be passed to the compiler and linker to produce 32-bit executables. Provided the supporting 32-bit libraries are installed on teh 64-bit system, this executable will be able to run on both 32-bit systems and 64-bit systems.

If you have not installed the 32-bit supporting libraries you will get an error similar to this for C code:

$ gcc -m32 hello32.c -o hello32
/usr/bin/ld: crt1.o: No such file: No such file or directory
collect2: ld returned 1 exit status

A similar error would be triggered on C++ code:

$ g++ -m32 hello32.cc -o hello32-c++
In file included from /usr/include/features.h:385,
     from /usr/lib/gcc/x86_64-redhat-linux/4.4.4/../../../../include/c++/4.4.4/x86_64-redhat-linux/32/bits/os_defines.h:39,
     from /usr/lib/gcc/x86_64-redhat-linux/4.4.4/../../../../include/c++/4.4.4/x86_64-redhat-linux/32/bits/c++config.h:243,
     from /usr/lib/gcc/x86_64-redhat-linux/4.4.4/../../../../include/c++/4.4.4/iostream:39,
     from hello32.cc:1:
/usr/include/gnu/stubs.h:7:27: error: gnu/stubs-32.h: No such file or directory

These errors indicate that the supporting 32-bit libraries have not been properly installed as explained at the beginning of this section.

It is important to note that even if 32-bit binaries can run on 64-bit systems, it is preferrable to have 64-bit binaries unless otherwise needed. In order to run 32-bit binaries on 64-bit systems, the system must import additional 32-bit shared libraries that must be loaded in tandem with the 64-bit libraries (for example glibc). This causes additional memory usage on such systems. It is always preferrable to have 64-bit binaries for 64-bit systems and 32-bit binaries for 32-bit systems.

Also important is to note that building with -m32 will in not adapt or convert a program to resolve any issues arising from 32/64-bit incompatibilities. For tips on writing portable code and converting from 32-bits to 64-bits, see the paper entitled Porting to 64-bit GNU/Linux Systems in the Proceedings of the 2003 GCC Developers Summit.