Split print_rtx into subroutines
[official-gcc.git] / gcc / go / gccgo.texi
blob04ce3e996c737e8164efa50fabff2b9d3f4ce0e1
1 \input texinfo @c -*-texinfo-*-
2 @setfilename gccgo.info
3 @settitle The GNU Go Compiler
5 @c Merge the standard indexes into a single one.
6 @syncodeindex fn cp
7 @syncodeindex vr cp
8 @syncodeindex ky cp
9 @syncodeindex pg cp
10 @syncodeindex tp cp
12 @include gcc-common.texi
14 @c Copyright years for this manual.
15 @set copyrights-go 2010-2016
17 @copying
18 @c man begin COPYRIGHT
19 Copyright @copyright{} @value{copyrights-go} Free Software Foundation, Inc.
21 Permission is granted to copy, distribute and/or modify this document
22 under the terms of the GNU Free Documentation License, Version 1.3 or
23 any later version published by the Free Software Foundation; with no
24 Invariant Sections, the Front-Cover Texts being (a) (see below), and
25 with the Back-Cover Texts being (b) (see below).
26 A copy of the license is included in the
27 @c man end
28 section entitled ``GNU Free Documentation License''.
29 @ignore
30 @c man begin COPYRIGHT
31 man page gfdl(7).
32 @c man end
33 @end ignore
35 @c man begin COPYRIGHT
37 (a) The FSF's Front-Cover Text is:
39      A GNU Manual
41 (b) The FSF's Back-Cover Text is:
43      You have freedom to copy and modify this GNU Manual, like GNU
44      software.  Copies published by the Free Software Foundation raise
45      funds for GNU development.
46 @c man end
47 @end copying
49 @ifinfo
50 @format
51 @dircategory Software development
52 @direntry
53 * Gccgo: (gccgo).           A GCC-based compiler for the Go language
54 @end direntry
55 @end format
57 @insertcopying
58 @end ifinfo
60 @titlepage
61 @title The GNU Go Compiler
62 @versionsubtitle
63 @author Ian Lance Taylor
65 @page
66 @vskip 0pt plus 1filll
67 Published by the Free Software Foundation @*
68 51 Franklin Street, Fifth Floor@*
69 Boston, MA 02110-1301, USA@*
70 @sp 1
71 @insertcopying
72 @end titlepage
73 @contents
74 @page
76 @node Top
77 @top Introduction
79 This manual describes how to use @command{gccgo}, the GNU compiler for
80 the Go programming language.  This manual is specifically about
81 @command{gccgo}.  For more information about the Go programming
82 language in general, including language specifications and standard
83 package documentation, see @uref{http://golang.org/}.
85 @menu
86 * Copying::                     The GNU General Public License.
87 * GNU Free Documentation License::
88                                 How you can share and copy this manual.
89 * Invoking gccgo::              How to run gccgo.
90 * Import and Export::           Importing and exporting package data.
91 * Compiler Directives::         Comments to control compilation.
92 * C Interoperability::          Calling C from Go and vice-versa.
93 * Index::                       Index.
94 @end menu
97 @include gpl_v3.texi
99 @include fdl.texi
102 @node Invoking gccgo
103 @chapter Invoking gccgo
105 @c man title gccgo A GCC-based compiler for the Go language
107 @ignore
108 @c man begin SYNOPSIS gccgo
109 gccgo [@option{-c}|@option{-S}]
110       [@option{-g}] [@option{-pg}] [@option{-O}@var{level}]
111       [@option{-I}@var{dir}@dots{}] [@option{-L}@var{dir}@dots{}]
112       [@option{-o} @var{outfile}] @var{infile}@dots{}
114 Only the most useful options are listed here; see below for the
115 remainder.
116 @c man end
117 @c man begin SEEALSO
118 gpl(7), gfdl(7), fsf-funding(7), gcc(1)
119 and the Info entries for @file{gccgo} and @file{gcc}.
120 @c man end
121 @end ignore
123 @c man begin DESCRIPTION gccgo
125 The @command{gccgo} command is a frontend to @command{gcc} and
126 supports many of the same options.  @xref{Option Summary, , Option
127 Summary, gcc, Using the GNU Compiler Collection (GCC)}.  This manual
128 only documents the options specific to @command{gccgo}.
130 The @command{gccgo} command may be used to compile Go source code into
131 an object file, link a collection of object files together, or do both
132 in sequence.
134 Go source code is compiled as packages.  A package consists of one or
135 more Go source files.  All the files in a single package must be
136 compiled together, by passing all the files as arguments to
137 @command{gccgo}.  A single invocation of @command{gccgo} may only
138 compile a single package.
140 One Go package may @code{import} a different Go package.  The imported
141 package must have already been compiled; @command{gccgo} will read
142 the import data directly from the compiled package.  When this package
143 is later linked, the compiled form of the package must be included in
144 the link command.
146 Go programs must generally be compiled with debugging information, and
147 @option{-g1} is the default as described below.  Stripping a Go
148 program will generally cause it to misbehave or fail.
150 @c man end
152 @c man begin OPTIONS gccgo
154 @table @gcctabopt
155 @item -I@var{dir}
156 @cindex @option{-I}
157 Specify a directory to use when searching for an import package at
158 compile time.
160 @item -L@var{dir}
161 @cindex @option{-L}
162 When linking, specify a library search directory, as with
163 @command{gcc}.
165 @item -fgo-pkgpath=@var{string}
166 @cindex @option{-fgo-pkgpath}
167 Set the package path to use.  This sets the value returned by the
168 PkgPath method of reflect.Type objects.  It is also used for the names
169 of globally visible symbols.  The argument to this option should
170 normally be the string that will be used to import this package after
171 it has been installed; in other words, a pathname within the
172 directories specified by the @option{-I} option.
174 @item -fgo-prefix=@var{string}
175 @cindex @option{-fgo-prefix}
176 An alternative to @option{-fgo-pkgpath}.  The argument will be
177 combined with the package name from the source file to produce the
178 package path.  If @option{-fgo-pkgpath} is used, @option{-fgo-prefix}
179 will be ignored.
181 Go permits a single program to include more than one package with the
182 same name in the @code{package} clause in the source file, though
183 obviously the two packages must be imported using different pathnames.
184 In order for this to work with @command{gccgo}, either
185 @option{-fgo-pkgpath} or @option{-fgo-prefix} must be specified when
186 compiling a package.
188 Using either @option{-fgo-pkgpath} or @option{-fgo-prefix} disables
189 the special treatment of the @code{main} package and permits that
190 package to be imported like any other.
192 @item -fgo-relative-import-path=@var{dir}
193 @cindex @option{-fgo-relative-import-path}
194 A relative import is an import that starts with @file{./} or
195 @file{../}.  If this option is used, @command{gccgo} will use
196 @var{dir} as a prefix for the relative import when searching for it.
198 @item -frequire-return-statement
199 @itemx -fno-require-return-statement
200 @cindex @option{-frequire-return-statement}
201 @cindex @option{-fno-require-return-statement}
202 By default @command{gccgo} will warn about functions which have one or
203 more return parameters but lack an explicit @code{return} statement.
204 This warning may be disabled using
205 @option{-fno-require-return-statement}.
207 @item -fgo-check-divide-zero
208 @cindex @option{-fgo-check-divide-zero}
209 @cindex @option{-fno-go-check-divide-zero}
210 Add explicit checks for division by zero.  In Go a division (or
211 modulos) by zero causes a panic.  On Unix systems this is detected in
212 the runtime by catching the @code{SIGFPE} signal.  Some processors,
213 such as PowerPC, do not generate a SIGFPE on division by zero.  Some
214 runtimes do not generate a signal that can be caught.  On those
215 systems, this option may be used.  Or the checks may be removed via
216 @option{-fno-go-check-divide-zero}.  This option is currently on by
217 default, but in the future may be off by default on systems that do
218 not require it.
220 @item -fgo-check-divide-overflow
221 @cindex @option{-fgo-check-divide-overflow}
222 @cindex @option{-fno-go-check-divide-overflow}
223 Add explicit checks for division overflow.  For example, division
224 overflow occurs when computing @code{INT_MIN / -1}.  In Go this should
225 be wrapped, to produce @code{INT_MIN}.  Some processors, such as x86,
226 generate a trap on division overflow.  On those systems, this option
227 may be used.  Or the checks may be removed via
228 @option{-fno-go-check-divide-overflow}.  This option is currently on
229 by default, but in the future may be off by default on systems that do
230 not require it.
232 @item -fgo-optimize-allocs
233 @cindex @option{-fgo-optimize-allocs}
234 Use escape analysis to allocate objects on the stack rather than the
235 heap when possible.  In the future this may be the default.
237 @item -fgo-debug-escape@var{n}
238 @cindex @option{-fgo-debug-escape}
239 Output escape analysis debugging information.  Larger values of
240 @var{n} generate more information.
242 @item -fgo-c-header=@var{file}
243 @cindex @option{-fgo-c-header}
244 Write top-level named Go struct definitions to @var{file} as C code.
245 This is used when compiling the runtime package.
247 @item -fgo-compiling-runtime
248 @cindex @option{-fgo-compiling-runtime}
249 Apply special rules for compiling the runtime package.  Implicit
250 memory allocation is forbidden.  Some additional compiler directives
251 are supported.
253 @item -g
254 @cindex @option{-g for gccgo}
255 This is the standard @command{gcc} option (@pxref{Debugging Options, ,
256 Debugging Options, gcc, Using the GNU Compiler Collection (GCC)}).  It
257 is mentioned here because by default @command{gccgo} turns on
258 debugging information generation with the equivalent of the standard
259 option @option{-g1}.  This is because Go programs require debugging
260 information to be available in order to get backtrace information.  An
261 explicit @option{-g0} may be used to disable the generation of
262 debugging information, in which case certain standard library
263 functions, such as @code{runtime.Callers}, will not operate correctly.
264 @end table
266 @c man end
268 @node Import and Export
269 @chapter Import and Export
271 When @command{gccgo} compiles a package which exports anything, the
272 export information will be stored directly in the object file.  When a
273 package is imported, @command{gccgo} must be able to find the file.
275 @cindex @file{.gox}
276 When Go code imports the package @file{@var{gopackage}}, @command{gccgo}
277 will look for the import data using the following filenames, using the
278 first one that it finds.
280 @table @file
281 @item @var{gopackage}.gox
282 @item lib@var{gopackage}.so
283 @item lib@var{gopackage}.a
284 @item @var{gopackage}.o
285 @end table
287 The compiler will search for these files in the directories named by
288 any @option{-I} options, in order in which the directories appear on
289 the command line.  The compiler will then search several standard
290 system directories.  Finally the compiler will search the current
291 directory (to search the current directory earlier, use @samp{-I.}).
293 The compiler will extract the export information directly from the
294 compiled object file.  The file @file{@var{gopackage}.gox} will
295 typically contain nothing but export data.  This can be generated from
296 @file{@var{gopackage}.o} via
298 @smallexample
299 objcopy -j .go_export @var{gopackage}.o @var{gopackage}.gox
300 @end smallexample
302 For example, it may be desirable to extract the export information
303 from several different packages into their independent
304 @file{@var{gopackage}.gox} files, and then to combine the different
305 package object files together into a single shared library or archive.
307 At link time you must explicitly tell @command{gccgo} which files to
308 link together into the executable, as is usual with @command{gcc}.
309 This is different from the behavior of other Go compilers.
311 @node Compiler Directives
312 @chapter Compiler Directives
314 The Go compiler supports a few compiler directives.  A compiler
315 directive uses a @code{//} comment at the start of a line.  There must
316 be no space between the @code{//} and the name of the directive.
318 @table @code
319 @item //line @var{file}:@var{line}
320 The @code{//line} directive specifies that the source line that
321 follows should be recorded as having come from the given file path and
322 line number.  Successive lines are recorded using increasing line
323 numbers, until the next directive.  This directive typically appears
324 in machine-generated code, so that compilers and debuggers will show
325 lines in the original input to the generator.
327 @item //extern @var{extern_name}
328 The @code{extern} directive sets the externally visible name of the
329 next function declaration.  See @ref{Function Names}.
331 @item //go:compile @var{go_name} @var{extern_name}
332 The @code{go:compile} directives sets the externally visible name of a
333 function definition or declaration.  See @ref{Function Names}.
335 @item //go:noescape
336 The @code{//go:noescape} directive specifies that the next declaration
337 in the file, which must be a func without a body (meaning that it has
338 an implementation not written in Go) does not allow any of the
339 pointers passed as arguments to escape into the heap or into the
340 values returned from the function. This information can be used during
341 the compiler's escape analysis of Go code calling the function.
343 @item //go:nosplit
344 The @code{//go:nosplit} directive specifies that the next function
345 declared in the file must not include a stack overflow check. This is
346 most commonly used by low-level runtime sources invoked at times when
347 it is unsafe for the calling goroutine to be preempted.
349 @item //go:noinline
350 The @code{//go:noinline} directive specifies that the next function
351 defined in the file may not be inlined.
353 @end table
355 @node C Interoperability
356 @chapter C Interoperability
358 When using @command{gccgo} there is limited interoperability with C,
359 or with C++ code compiled using @code{extern "C"}.
361 This information is provided largely for documentation purposes.  For
362 ordinary use it is best to build programs with the go tool and then
363 use @code{import "C"}, as described at
364 @url{http://golang.org/cmd/cgo}.
366 @menu
367 * C Type Interoperability::     How C and Go types match up.
368 * Function Names::              How Go functions are named.
369 @end menu
371 @node C Type Interoperability
372 @section C Type Interoperability
374 Basic types map directly: an @code{int} in Go is an @code{int} in C,
375 etc.  Go @code{byte} is equivalent to C @code{unsigned char}.
376 Pointers in Go are pointers in C.  A Go @code{struct} is the same as C
377 @code{struct} with the same field names and types.
379 @cindex @code{string} in C
380 The Go @code{string} type is currently defined as a two-element
381 structure:
383 @smallexample
384 struct __go_string @{
385   const unsigned char *__data;
386   int __length;
388 @end smallexample
390 You can't pass arrays between C and Go.  However, a pointer to an
391 array in Go is equivalent to a C pointer to the equivalent of the
392 element type.  For example, Go @code{*[10]int} is equivalent to C
393 @code{int*}, assuming that the C pointer does point to 10 elements.
395 @cindex @code{slice} in C
396 A slice in Go is a structure.  The current definition is:
398 @smallexample
399 struct __go_slice @{
400   void *__values;
401   int __count;
402   int __capacity;
404 @end smallexample
406 The type of a Go function with no receiver is equivalent to a C
407 function whose parameter types are equivalent.  When a Go function
408 returns more than one value, the C function returns a struct.  For
409 example, these functions have equivalent types:
411 @smallexample
412 func GoFunction(int) (int, float)
413 struct @{ int i; float f; @} CFunction(int)
414 @end smallexample
416 A pointer to a Go function is equivalent to a pointer to a C function
417 when the functions have equivalent types.
419 Go @code{interface}, @code{channel}, and @code{map} types have no
420 corresponding C type (@code{interface} is a two-element struct and
421 @code{channel} and @code{map} are pointers to structs in C, but the
422 structs are deliberately undocumented).  C @code{enum} types
423 correspond to some integer type, but precisely which one is difficult
424 to predict in general; use a cast.  C @code{union} types have no
425 corresponding Go type.  C @code{struct} types containing bitfields
426 have no corresponding Go type.  C++ @code{class} types have no
427 corresponding Go type.
429 Memory allocation is completely different between C and Go, as Go uses
430 garbage collection.  The exact guidelines in this area are
431 undetermined, but it is likely that it will be permitted to pass a
432 pointer to allocated memory from C to Go.  The responsibility of
433 eventually freeing the pointer will remain with C side, and of course
434 if the C side frees the pointer while the Go side still has a copy the
435 program will fail.  When passing a pointer from Go to C, the Go
436 function must retain a visible copy of it in some Go variable.
437 Otherwise the Go garbage collector may delete the pointer while the C
438 function is still using it.
440 @node Function Names
441 @section Function Names
443 @cindex @code{extern}
444 @cindex external names
445 Go code can call C functions directly using the @code{//extern} or
446 @code{//go:linkname} compiler directives.  An @code{//extern}
447 directive must be at the beginning of the line and must start with
448 @code{//extern}.  This must be followed by a space and then the
449 external name of the function.  The function declaration must be on
450 the line immediately after the comment.  For example, here is how the
451 C function @code{open} can be declared in Go:
453 @smallexample
454 //extern open
455 func c_open(name *byte, mode int, perm int) int
456 @end smallexample
458 You can do the same thing using the @code{//go:linkname} compiler
459 directive.  The @code{//go:linkname} directive must be at the start of
460 the line.  It is followed by whitespace, the name of the Go function,
461 more whitespace, and the external name of the function.  Unlike
462 @code{//extern}, @code{//go:linkname} does not need to appear
463 immediately adjacent to the function definition or declaration.
465 @smallexample
466 //go:linkname c_open open
467 func c_open(name *byte, mode int, perm int) int
468 @end smallexample
470 The C function naturally expects a nul terminated string, which in Go
471 is equivalent to a pointer to an array (not a slice!) of @code{byte}
472 with a terminating zero byte.  So a sample call from Go would look
473 like (after importing the @code{os} package):
475 @smallexample
476 var name = [4]byte@{'f', 'o', 'o', 0@};
477 i := c_open(&name[0], os.O_RDONLY, 0);
478 @end smallexample
480 Note that this serves as an example only.  To open a file in Go please
481 use Go's @code{os.Open} function instead.
483 The name of Go functions accessed from C is subject to change.  At
484 present the name of a Go function that does not have a receiver is
485 @code{pkgpath.Functionname}.  The @var{pkgpath} is set by the
486 @option{-fgo-pkgpath} option used when the package is compiled; if the
487 option is not used, the default is @code{go.@var{packagename}}.  To
488 call the function from C you must set the name using the @command{gcc}
489 @code{__asm__} extension.
491 @smallexample
492 extern int go_function(int) __asm__ ("mypkgpath.Function");
493 @end smallexample
495 @node Index
496 @unnumbered Index
498 @printindex cp
500 @bye