1 Invoking gccgo

The gccgo command is a frontend to gcc and supports many of the same options. See Option Summary. This manual only documents the options specific to gccgo.

The gccgo command may be used to compile Go source code into an object file, link a collection of object files together, or do both in sequence.

Go source code is compiled as packages. A package consists of one or more Go source files. All the files in a single package must be compiled together, by passing all the files as arguments to gccgo. A single invocation of gccgo may only compile a single package.

One Go package may import a different Go package. The imported package must have already been compiled; gccgo will read the import data directly from the compiled package. When this package is later linked, the compiled form of the package must be included in the link command.

Go programs must generally be compiled with debugging information, and -g1 is the default as described below. Stripping a Go program will generally cause it to misbehave or fail.

-Idir

Specify a directory to use when searching for an import package at compile time.

-Ldir

When linking, specify a library search directory, as with gcc.

-fgo-pkgpath=string

Set the package path to use. This sets the value returned by the PkgPath method of reflect.Type objects. It is also used for the names of globally visible symbols. The argument to this option should normally be the string that will be used to import this package after it has been installed; in other words, a pathname within the directories specified by the -I option.

-fgo-prefix=string

An alternative to -fgo-pkgpath. The argument will be combined with the package name from the source file to produce the package path. If -fgo-pkgpath is used, -fgo-prefix will be ignored.

Go permits a single program to include more than one package with the same name in the package clause in the source file, though obviously the two packages must be imported using different pathnames. In order for this to work with gccgo, either -fgo-pkgpath or -fgo-prefix must be specified when compiling a package.

Using either -fgo-pkgpath or -fgo-prefix disables the special treatment of the main package and permits that package to be imported like any other.

-fgo-relative-import-path=dir

A relative import is an import that starts with ./ or ../. If this option is used, gccgo will use dir as a prefix for the relative import when searching for it.

-frequire-return-statement

-fno-require-return-statement

By default gccgo will warn about functions which have one or more return parameters but lack an explicit return statement. This warning may be disabled using -fno-require-return-statement.

-fgo-check-divide-zero

Add explicit checks for division by zero. In Go a division (or modulos) by zero causes a panic. On Unix systems this is detected in the runtime by catching the SIGFPE signal. Some processors, such as PowerPC, do not generate a SIGFPE on division by zero. Some runtimes do not generate a signal that can be caught. On those systems, this option may be used. Or the checks may be removed via -fno-go-check-divide-zero. This option is currently on by default, but in the future may be off by default on systems that do not require it.

-fgo-check-divide-overflow

Add explicit checks for division overflow. For example, division overflow occurs when computing INT_MIN / -1. In Go this should be wrapped, to produce INT_MIN. Some processors, such as x86, generate a trap on division overflow. On those systems, this option may be used. Or the checks may be removed via -fno-go-check-divide-overflow. This option is currently on by default, but in the future may be off by default on systems that do not require it.

-g

This is the standard gcc option (see Debugging Options). It is mentioned here because by default gccgo turns on debugging information generation with the equivalent of the standard option -g1. This is because Go programs require debugging information to be available in order to get backtrace information. An explicit -g0 may be used to disable the generation of debugging information, in which case certain standard library functions, such as runtime.Callers, will not operate correctly.