1 \input texinfo @c -*-texinfo-*-
3 @setfilename gfc-internals.info
4 @set copyrights-gfortran 2007-2008
6 @include gcc-common.texi
10 @settitle GNU Fortran Compiler Internals
14 @c Use with @@smallbook.
16 @c %** start of document
18 @c Cause even numbered pages to be printed on the left hand side of
19 @c the page and odd numbered pages to be printed on the right hand
20 @c side of the page. Using this, you can print on both sides of a
21 @c sheet of paper and have the text on the same part of the sheet.
23 @c The text on right hand pages is pushed towards the right hand
24 @c margin and the text on left hand pages is pushed toward the left
26 @c (To provide the reverse effect, set bindingoffset to -0.75in.)
29 @c \global\bindingoffset=0.75in
30 @c \global\normaloffset =0.75in
34 Copyright @copyright{} @value{copyrights-gfortran} Free Software Foundation, Inc.
36 Permission is granted to copy, distribute and/or modify this document
37 under the terms of the GNU Free Documentation License, Version 1.2 or
38 any later version published by the Free Software Foundation; with the
39 Invariant Sections being ``Funding Free Software'', the Front-Cover
40 Texts being (a) (see below), and with the Back-Cover Texts being (b)
41 (see below). A copy of the license is included in the section entitled
42 ``GNU Free Documentation License''.
44 (a) The FSF's Front-Cover Text is:
48 (b) The FSF's Back-Cover Text is:
50 You have freedom to copy and modify this GNU Manual, like GNU
51 software. Copies published by the Free Software Foundation raise
52 funds for GNU development.
56 @dircategory Software development
58 * gfortran: (gfortran). The GNU Fortran Compiler.
60 This file documents the internals of the GNU Fortran
61 compiler, (@command{gfortran}).
63 Published by the Free Software Foundation
64 51 Franklin Street, Fifth Floor
65 Boston, MA 02110-1301 USA
71 @setchapternewpage odd
73 @title GNU Fortran Internals
75 @author The @t{gfortran} team
77 @vskip 0pt plus 1filll
78 Published by the Free Software Foundation@*
79 51 Franklin Street, Fifth Floor@*
80 Boston, MA 02110-1301, USA@*
81 @c Last printed ??ber, 19??.@*
82 @c Printed copies are available for $? each.@*
93 @c ---------------------------------------------------------------------
94 @c TexInfo table of contents.
95 @c ---------------------------------------------------------------------
102 This manual documents the internals of @command{gfortran},
103 the GNU Fortran compiler.
106 @emph{Warning:} This document, and the compiler it describes, are still
107 under development. While efforts are made to keep it up-to-date, it might
108 not accurately reflect the status of the most recent GNU Fortran compiler.
112 @comment When you add a new menu item, please keep the right hand
113 @comment aligned to the same column. Do not use tabs. This provides
114 @comment better formatting.
117 * Introduction:: About this manual.
118 * User Interface:: Code that Interacts with the User.
119 * Frontend Data Structures::
120 Data structures used by the frontend
121 * Object Orientation:: Internals of Fortran 2003 OOP features.
122 * LibGFortran:: The LibGFortran Runtime Library.
123 * GNU Free Documentation License::
124 How you can copy and share this manual.
125 * Index:: Index of this documentation.
129 @c ---------------------------------------------------------------------
131 @c ---------------------------------------------------------------------
134 @chapter Introduction
136 @c The following duplicates the text on the TexInfo table of contents.
138 This manual documents the internals of @command{gfortran}, the GNU Fortran
142 @emph{Warning:} This document, and the compiler it describes, are still
143 under development. While efforts are made to keep it up-to-date, it
144 might not accurately reflect the status of the most recent GNU Fortran
149 At present, this manual is very much a work in progress, containing
150 miscellaneous notes about the internals of the compiler. It is hoped
151 that at some point in the future it will become a reasonably complete
152 guide; in the interim, GNU Fortran developers are strongly encouraged to
153 contribute to it as a way of keeping notes while working on the
157 @c ---------------------------------------------------------------------
158 @c Code that Interacts with the User
159 @c ---------------------------------------------------------------------
162 @chapter Code that Interacts with the User
165 * Command-Line Options:: Command-Line Options.
166 * Error Handling:: Error Handling.
170 @c ---------------------------------------------------------------------
171 @c Command-Line Options
172 @c ---------------------------------------------------------------------
174 @node Command-Line Options
175 @section Command-Line Options
177 Command-line options for @command{gfortran} involve four interrelated
178 pieces within the Fortran compiler code.
180 The relevant command-line flag is defined in @file{lang.opt}, according
181 to the documentation in @ref{Options,, Options, gccint, GNU Compiler
182 Collection Internals}. This is then processed by the overall GCC
183 machinery to create the code that enables @command{gfortran} and
184 @command{gcc} to recognize the option in the command-line arguments and
185 call the relevant handler function.
187 This generated code calls the @code{gfc_handle_option} code in
188 @file{options.c} with an enumerator variable indicating which option is
189 to be processed, and the relevant integer or string values associated
190 with that option flag. Typically, @code{gfc_handle_option} uses these
191 arguments to set global flags which record the option states.
193 The global flags that record the option states are stored in the
194 @code{gfc_option_t} struct, which is defined in @file{gfortran.h}.
195 Before the options are processed, initial values for these flags are set
196 in @code{gfc_init_option} in @file{options.c}; these become the default
197 values for the options.
201 @c ---------------------------------------------------------------------
203 @c ---------------------------------------------------------------------
206 @section Error Handling
208 The GNU Fortran compiler's parser operates by testing each piece of
209 source code against a variety of matchers. In some cases, if these
210 matchers do not match the source code, they will store an error message
211 in a buffer. If the parser later finds a matcher that does correctly
212 match the source code, then the buffered error is discarded. However,
213 if the parser cannot find a match, then the buffered error message is
214 reported to the user. This enables the compiler to provide more
215 meaningful error messages even in the many cases where (erroneous)
216 Fortran syntax is ambiguous due to things like the absence of reserved
219 As an example of how this works, consider the following line:
223 Hypothetically, this may get passed to the matcher for an @code{IF}
224 statement. Since this could plausibly be an erroneous @code{IF}
225 statement, the matcher will buffer an error message reporting the
226 absence of an expected @samp{(} following an @code{IF}. Since no
227 matchers reported an error-free match, however, the parser will also try
228 matching this against a variable assignment. When @code{IF} is a valid
229 variable, this will be parsed as an assignment statement, and the error
230 discarded. However, when @code{IF} is not a valid variable, this
231 buffered error message will be reported to the user.
233 The error handling code is implemented in @file{error.c}. Errors are
234 normally entered into the buffer with the @code{gfc_error} function.
235 Warnings go through a similar buffering process, and are entered into
236 the buffer with @code{gfc_warning}. There is also a special-purpose
237 function, @code{gfc_notify_std}, for things which have an error/warning
238 status that depends on the currently-selected language standard.
240 The @code{gfc_error_check} function checks the buffer for errors,
241 reports the error message to the user if one exists, clears the buffer,
242 and returns a flag to the user indicating whether or not an error
243 existed. To check the state of the buffer without changing its state or
244 reporting the errors, the @code{gfc_error_flag_test} function can be
245 used. The @code{gfc_clear_error} function will clear out any errors in
246 the buffer, without reporting them. The @code{gfc_warning_check} and
247 @code{gfc_clear_warning} functions provide equivalent functionality for
250 Only one error and one warning can be in the buffers at a time, and
251 buffering another will overwrite the existing one. In cases where one
252 may wish to work on a smaller piece of source code without disturbing an
253 existing error state, the @code{gfc_push_error}, @code{gfc_pop_error},
254 and @code{gfc_free_error} mechanism exists to implement a stack for the
257 For cases where an error or warning should be reported immediately
258 rather than buffered, the @code{gfc_error_now} and
259 @code{gfc_warning_now} functions can be used. Normally, the compiler
260 will continue attempting to parse the program after an error has
261 occurred, but if this is not appropriate, the @code{gfc_fatal_error}
262 function should be used instead. For errors that are always the result
263 of a bug somewhere in the compiler, the @code{gfc_internal_error}
264 function should be used.
266 The syntax for the strings used to produce the error/warning message in
267 the various error and warning functions is similar to the @code{printf}
268 syntax, with @samp{%}-escapes to insert variable values. The details,
269 and the allowable codes, are documented in the @code{error_print}
270 function in @file{error.c}.
272 @c ---------------------------------------------------------------------
273 @c Frontend Data Structures
274 @c ---------------------------------------------------------------------
276 @node Frontend Data Structures
277 @chapter Frontend Data Structures
278 @cindex data structures
280 This chapter should describe the details necessary to understand how
281 the various @code{gfc_*} data are used and interact. In general it is
282 advisable to read the code in @file{dump-parse-tree.c} as its routines
283 should exhaust all possible valid combinations of content for these
287 * gfc_code:: Representation of Executable Statements.
288 * gfc_expr:: Representation of Values and Expressions.
296 @section @code{gfc_code}
297 @cindex statement chaining
298 @tindex @code{gfc_code}
299 @tindex @code{struct gfc_code}
301 The executable statements in a program unit are represented by a
302 nested chain of @code{gfc_code} structures. The type of statement is
303 identified by the @code{op} member of the structure, the different
304 possible values are enumerated in @code{gfc_exec_op}. A special
305 member of this @code{enum} is @code{EXEC_NOP} which is used to
306 represent the various @code{END} statements if they carry a label.
307 Depending on the type of statement some of the other fields will be
308 filled in. Fields that are generally applicable are the @code{next}
309 and @code{here} fields. The former points to the next statement in
310 the current block or is @code{NULL} if the current statement is the
311 last in a block, @code{here} points to the statement label of the
314 If the current statement is one of @code{IF}, @code{DO}, @code{SELECT}
315 it starts a block, i.e.@: a nested level in the program. In order to
316 represent this, the @code{block} member is set to point to a
317 @code{gfc_code} structure whose @code{next} member starts the chain of
318 statements inside the block; this structure's @code{op} member should be set to
319 the same value as the parent structure's @code{op} member. The @code{SELECT}
320 and @code{IF} statements may contain various blocks (the chain of @code{ELSE IF}
321 and @code{ELSE} blocks or the various @code{CASE}s, respectively). These chains
322 are linked-lists formed by the @code{block} members.
324 Consider the following example code:
330 ELSEIF (foo > 50) THEN
338 This statement-block will be represented in the internal gfortran tree as
339 follows, were the horizontal link-chains are those induced by the @code{next}
340 members and vertical links down are those of @code{block}. @samp{==|} and
341 @samp{--|} mean @code{NULL} pointers to mark the end of a chain:
346 +--> IF foo < 20 ==> PRINT *, "Too small" ==> foo = 20 ==|
348 +--> IF foo > 50 ==> PRINT *, "Too large" ==> foo = 50 ==|
350 +--> ELSE ==> PRINT *, "Good" ==|
356 @subsection IF Blocks
358 Conditionals are represented by @code{gfc_code} structures with their
359 @code{op} member set to @code{EXEC_IF}. This structure's @code{block}
360 member must point to another @code{gfc_code} node that is the header of the
361 if-block. This header's @code{op} member must be set to @code{EXEC_IF}, too,
362 its @code{expr} member holds the condition to check for, and its @code{next}
363 should point to the code-chain of the statements to execute if the condition is
366 If in addition an @code{ELSEIF} or @code{ELSE} block is present, the
367 @code{block} member of the if-block-header node points to yet another
368 @code{gfc_code} structure that is the header of the elseif- or else-block. Its
369 structure is identical to that of the if-block-header, except that in case of an
370 @code{ELSE} block without a new condition the @code{expr} member should be
371 @code{NULL}. This block can itself have its @code{block} member point to the
372 next @code{ELSEIF} or @code{ELSE} block if there's a chain of them.
377 @code{DO} loops are stored in the tree as @code{gfc_code} nodes with their
378 @code{op} set to @code{EXEC_DO} for a @code{DO} loop with iterator variable and
379 to @code{EXEC_DO_WHILE} for infinite @code{DO}s and @code{DO WHILE} blocks.
380 Their @code{block} member should point to a @code{gfc_code} structure heading
381 the code-chain of the loop body; its @code{op} member should be set to
382 @code{EXEC_DO} or @code{EXEC_DO_WHILE}, too, respectively.
384 For @code{DO WHILE} loops, the loop condition is stored on the top
385 @code{gfc_code} structure's @code{expr} member; @code{DO} forever loops are
386 simply @code{DO WHILE} loops with a constant @code{.TRUE.} loop condition in
387 the internal representation.
389 Similarly, @code{DO} loops with an iterator have instead of the condition their
390 @code{ext.iterator} member set to the correct values for the loop iterator
391 variable and its range.
394 @subsection @code{SELECT} Statements
396 A @code{SELECT} block is introduced by a @code{gfc_code} structure with an
397 @code{op} member of @code{EXEC_SELECT} and @code{expr} containing the expression
398 to evaluate and test. Its @code{block} member starts a list of @code{gfc_code}
399 structures linked together by their @code{block} members that stores the various
402 Each @code{CASE} node has its @code{op} member set to @code{EXEC_SELECT}, too,
403 its @code{next} member points to the code-chain to be executed in the current
404 case-block, and @code{extx.case_list} contains the case-values this block
405 corresponds to. The @code{block} member links to the next case in the list.
412 @section @code{gfc_expr}
413 @tindex @code{gfc_expr}
414 @tindex @code{struct gfc_expr}
416 Expressions and ``values'', including constants, variable-, array- and
417 component-references as well as complex expressions consisting of operators and
418 function calls are internally represented as one or a whole tree of
419 @code{gfc_expr} objects. The member @code{expr_type} specifies the overall
420 type of an expression (for instance, @code{EXPR_CONSTANT} for constants or
421 @code{EXPR_VARIABLE} for variable references). The members @code{ts} and
422 @code{rank} as well as @code{shape}, which can be @code{NULL}, specify
423 the type, rank and, if applicable, shape of the whole expression or expression
424 tree of which the current structure is the root. @code{where} is the locus of
425 this expression in the source code.
427 Depending on the flavour of the expression being described by the object
428 (that is, the value of its @code{expr_type} member), the corresponding structure
429 in the @code{value} union will usually contain additional data describing the
430 expression's value in a type-specific manner. The @code{ref} member is used to
431 build chains of (array-, component- and substring-) references if the expression
432 in question contains such references, see below for details.
435 @subsection Constants
437 Scalar constants are represented by @code{gfc_expr} nodes with their
438 @code{expr_type} set to @code{EXPR_CONSTANT}. The constant's value shall
439 already be known at compile-time and is stored in the @code{logical},
440 @code{integer}, @code{real}, @code{complex} or @code{character} struct inside
441 @code{value}, depending on the constant's type specification.
444 @subsection Operators
446 Operator-expressions are expressions that are the result of the execution of
447 some operator on one or two operands. The expressions have an @code{expr_type}
448 of @code{EXPR_OP}. Their @code{value.op} structure contains additional data.
450 @code{op1} and optionally @code{op2} if the operator is binary point to the
451 two operands, and @code{operator} or @code{uop} describe the operator that
452 should be evaluated on these operands, where @code{uop} describes a user-defined
456 @subsection Function Calls
458 If the expression is the return value of a function-call, its @code{expr_type}
459 is set to @code{EXPR_FUNCTION}, and @code{symtree} must point to the symtree
460 identifying the function to be called. @code{value.function.actual} holds the
461 actual arguments given to the function as a linked list of
462 @code{gfc_actual_arglist} nodes.
464 The other members of @code{value.function} describe the function being called
465 in more detail, containing a link to the intrinsic symbol or user-defined
466 function symbol if the call is to an intrinsic or external function,
467 respectively. These values are determined during resolution-phase from the
468 structure's @code{symtree} member.
470 A special case of function calls are ``component calls'' to type-bound
471 procedures; those have the @code{expr_type} @code{EXPR_COMPCALL} with
472 @code{value.compcall} containing the argument list and the procedure called,
473 while @code{symtree} and @code{ref} describe the object on which the procedure
474 was called in the same way as a @code{EXPR_VARIABLE} expression would.
475 @xref{Type-bound Procedures}.
478 @subsection Array- and Structure-Constructors
480 Array- and structure-constructors (one could probably call them ``array-'' and
481 ``derived-type constants'') are @code{gfc_expr} structures with their
482 @code{expr_type} member set to @code{EXPR_ARRAY} or @code{EXPR_STRUCTURE},
483 respectively. For structure constructors, @code{symtree} points to the
484 derived-type symbol for the type being constructed.
486 The values for initializing each array element or structure component are
487 stored as linked-list of @code{gfc_constructor} nodes in the
488 @code{value.constructor} member.
493 @code{NULL} is a special value for pointers; it can be of different base types.
494 Such a @code{NULL} value is represented in the internal tree by a
495 @code{gfc_expr} node with @code{expr_type} @code{EXPR_NULL}. If the base type
496 of the @code{NULL} expression is known, it is stored in @code{ts} (that's for
497 instance the case for default-initializers of @code{ALLOCATABLE} components),
498 but this member can also be set to @code{BT_UNKNOWN} if the information is not
499 available (for instance, when the expression is a pointer-initializer
503 @subsection Variables and Reference Expressions
505 Variable references are @code{gfc_expr} structures with their @code{expr_type}
506 set to @code{EXPR_VARIABLE}; their @code{symtree} should point to the variable
509 For this type of expression, it's also possible to chain array-, component-
510 or substring-references to the original expression to get something like
511 @samp{struct%component(2:5)}, where @code{component} is either an array or
512 a @code{CHARACTER} member of @code{struct} that is of some derived-type. Such a
513 chain of references is achieved by a linked list headed by @code{ref} of the
514 @code{gfc_expr} node. For the example above it would be (@samp{==|} is the
515 last @code{NULL} pointer):
518 EXPR_VARIABLE(struct) ==> REF_COMPONENT(component) ==> REF_ARRAY(2:5) ==|
521 If @code{component} is a string rather than an array, the last element would be
522 a @code{REF_SUBSTRING} reference, of course. If the variable itself or some
523 component referenced is an array and the expression should reference the whole
524 array rather than being followed by an array-element or -section reference, a
525 @code{REF_ARRAY} reference must be built as the last element in the chain with
526 an array-reference type of @code{AR_FULL}. Consider this example code:
533 TYPE(mytype) :: variable
534 INTEGER :: local_array(5)
536 CALL do_something (variable%array, local_array)
539 The @code{gfc_expr} nodes representing the arguments to the @samp{do_something}
540 call will have a reference-chain like this:
543 EXPR_VARIABLE(variable) ==> REF_COMPONENT(array) ==> REF_ARRAY(FULL) ==|
544 EXPR_VARIABLE(local_array) ==> REF_ARRAY(FULL) ==|
548 @subsection Constant Substring References
550 @code{EXPR_SUBSTRING} is a special type of expression that encodes a substring
551 reference of a constant string, as in the following code snippet:
557 In this case, @code{value.character} contains the full string's data as if it
558 was a string constant, but the @code{ref} member is also set and points to a
559 substring reference as described in the subsection above.
562 @c ---------------------------------------------------------------------
564 @c ---------------------------------------------------------------------
566 @node Object Orientation
567 @chapter Internals of Fortran 2003 OOP Features
570 * Type-bound Procedures:: Type-bound procedures.
574 @c Type-bound procedures
575 @c ---------------------
577 @node Type-bound Procedures
578 @section Type-bound Procedures
580 Type-bound procedures are stored in the @code{tb_sym_root} of the namespace
581 @code{f2k_derived} associated with the derived-type symbol as @code{gfc_symtree}
582 nodes. The name and symbol of these symtrees corresponds to the binding-name
583 of the procedure, i.e. the name that is used to call it from the context of an
584 object of the derived-type.
586 In addition, this type of symtrees stores in @code{n.tb} a struct of type
587 @code{gfc_typebound_proc} containing the additional data needed: The
588 binding attributes (like @code{PASS} and @code{NOPASS}, @code{NON_OVERRIDABLE}
589 or the access-specifier), the binding's target(s) and, if the current binding
590 overrides or extends an inherited binding of the same name, @code{overridden}
591 points to this binding's @code{gfc_typebound_proc} structure.
594 @subsection Specific Bindings
595 @c --------------------------
597 For specific bindings (declared with @code{PROCEDURE}), if they have a
598 passed-object argument, the passed-object dummy argument is first saved by its
599 name, and later during resolution phase the corresponding argument is looked for
600 and its position remembered as @code{pass_arg_num} in @code{gfc_typebound_proc}.
601 The binding's target procedure is pointed-to by @code{u.specific}.
603 @code{DEFERRED} bindings are just like ordinary specific bindings, except
604 that their @code{deferred} flag is set of course and that @code{u.specific}
605 points to their ``interface'' defining symbol (might be an abstract interface)
606 instead of the target procedure.
608 At the moment, all type-bound procedure calls are statically dispatched and
609 transformed into ordinary procedure calls at resolution time; their actual
610 argument list is updated to include at the right position the passed-object
611 argument, if applicable, and then a simple procedure call to the binding's
612 target procedure is built. To handle dynamic dispatch in the future, this will
613 be extended to allow special code generation during the trans-phase to dispatch
614 based on the object's dynamic type.
617 @subsection Generic Bindings
618 @c -------------------------
620 Bindings declared as @code{GENERIC} store the specific bindings they target as
621 a linked list using nodes of type @code{gfc_tbp_generic} in @code{u.generic}.
622 For each specific target, the parser records its symtree and during resolution
623 this symtree is bound to the corresponding @code{gfc_typebound_proc} structure
624 of the specific target.
626 Calls to generic bindings are handled entirely in the resolution-phase, where
627 for the actual argument list present the matching specific binding is found
628 and the call's target procedure (@code{value.compcall.tbp}) is re-pointed to
629 the found specific binding and this call is subsequently handled by the logic
630 for specific binding calls.
633 @subsection Calls to Type-bound Procedures
634 @c ---------------------------------------
636 Calls to type-bound procedures are stored in the parse-tree as @code{gfc_expr}
637 nodes of type @code{EXPR_COMPCALL}. Their @code{value.compcall.actual} saves
638 the actual argument list of the call and @code{value.compcall.tbp} points to the
639 @code{gfc_typebound_proc} structure of the binding to be called. The object
640 in whose context the procedure was called is saved by combination of
641 @code{symtree} and @code{ref}, as if the expression was of type
642 @code{EXPR_VARIABLE}.
646 CALL myobj%procedure (arg1, arg2)
649 the @code{CALL} is represented in the parse-tree as a @code{gfc_code} node of
650 type @code{EXEC_COMPCALL}. The @code{expr} member of this node holds an
651 expression of type @code{EXPR_COMPCALL} of the same structure as mentioned above
652 except that its target procedure is of course a @code{SUBROUTINE} and not a
656 @c ---------------------------------------------------------------------
658 @c ---------------------------------------------------------------------
661 @chapter The LibGFortran Runtime Library
664 * Symbol Versioning:: Symbol Versioning.
668 @c ---------------------------------------------------------------------
670 @c ---------------------------------------------------------------------
672 @node Symbol Versioning
673 @section Symbol Versioning
674 @comment Based on http://gcc.gnu.org/wiki/SymbolVersioning,
675 @comment as of 2006-11-05, written by Janne Blomqvist.
677 In general, this capability exists only on a few platforms, thus there
678 is a need for configure magic so that it is used only on those targets
679 where it is supported.
681 The central concept in symbol versioning is the so-called map file,
682 which specifies the version node(s) exported symbols are labeled with.
683 Also, the map file is used to hide local symbols.
685 Some relevant references:
688 @uref{http://www.gnu.org/software/binutils/manual/ld-2.9.1/html_node/ld_25.html,
689 GNU @command{ld} manual}
692 @uref{http://people.redhat.com/drepper/symbol-versioning, ELF Symbol
693 Versioning - Ulrich Depper}
696 @uref{http://people.redhat.com/drepper/dsohowto.pdf, How to Write Shared
697 Libraries - Ulrich Drepper (see Chapter 3)}
701 If one adds a new symbol to a library that should be exported, the new
702 symbol should be mentioned in the map file and a new version node
703 defined, e.g., if one adds a new symbols @code{foo} and @code{bar} to
704 libgfortran for the next GCC release, the following should be added to
714 where @code{GFORTRAN_1.0} is the version node of the current release,
715 and @code{GFORTRAN_1.1} is the version node of the next release where
716 foo and bar are made available.
718 If one wants to change an existing interface, it is possible by using
719 some asm trickery (from the @command{ld} manual referenced above):
722 __asm__(".symver original_foo,foo@@");
723 __asm__(".symver old_foo,foo@@VERS_1.1");
724 __asm__(".symver old_foo1,foo@@VERS_1.2");
725 __asm__(".symver new_foo,foo@@VERS_2.0");
728 In this example, @code{foo@@} represents the symbol @code{foo} bound to
729 the unspecified base version of the symbol. The source file that
730 contains this example would define 4 C functions: @code{original_foo},
731 @code{old_foo}, @code{old_foo1}, and @code{new_foo}.
733 In this case the map file must contain @code{foo} in @code{VERS_1.1}
734 and @code{VERS_1.2} as well as in @code{VERS_2.0}.
737 @c ---------------------------------------------------------------------
738 @c GNU Free Documentation License
739 @c ---------------------------------------------------------------------
744 @c ---------------------------------------------------------------------
746 @c ---------------------------------------------------------------------