Lines Matching refs:code
180 pieces within the Fortran compiler code.
185 machinery to create the code that enables @command{gfortran} and
189 This generated code calls the @code{gfc_handle_option} code in
192 with that option flag. Typically, @code{gfc_handle_option} uses these
196 @code{gfc_option_t} struct, which is defined in @file{gfortran.h}.
198 in @code{gfc_init_option} in @file{options.c}; these become the default
211 source code against a variety of matchers. In some cases, if these
212 matchers do not match the source code, they will store an error message
214 match the source code, then the buffered error is discarded. However,
225 Hypothetically, this may get passed to the matcher for an @code{IF}
226 statement. Since this could plausibly be an erroneous @code{IF}
228 absence of an expected @samp{(} following an @code{IF}. Since no
230 matching this against a variable assignment. When @code{IF} is a valid
232 discarded. However, when @code{IF} is not a valid variable, this
235 The error handling code is implemented in @file{error.c}. Errors are
236 normally entered into the buffer with the @code{gfc_error} function.
238 the buffer with @code{gfc_warning}. There is also a special-purpose
239 function, @code{gfc_notify_std}, for things which have an error/warning
242 The @code{gfc_error_check} function checks the buffer for errors,
246 reporting the errors, the @code{gfc_error_flag_test} function can be
247 used. The @code{gfc_clear_error} function will clear out any errors in
248 the buffer, without reporting them. The @code{gfc_warning_check} and
249 @code{gfc_clear_warning} functions provide equivalent functionality for
254 may wish to work on a smaller piece of source code without disturbing an
255 existing error state, the @code{gfc_push_error}, @code{gfc_pop_error},
256 and @code{gfc_free_error} mechanism exists to implement a stack for the
260 rather than buffered, the @code{gfc_error_now} and
261 @code{gfc_warning_now} functions can be used. Normally, the compiler
263 occurred, but if this is not appropriate, the @code{gfc_fatal_error}
265 of a bug somewhere in the compiler, the @code{gfc_internal_error}
269 the various error and warning functions is similar to the @code{printf}
271 and the allowable codes, are documented in the @code{error_print}
283 the various @code{gfc_*} data are used and interact. In general it is
284 advisable to read the code in @file{dump-parse-tree.c} as its routines
298 @section @code{gfc_code}
300 @tindex @code{gfc_code}
301 @tindex @code{struct gfc_code}
304 nested chain of @code{gfc_code} structures. The type of statement is
305 identified by the @code{op} member of the structure, the different
306 possible values are enumerated in @code{gfc_exec_op}. A special
307 member of this @code{enum} is @code{EXEC_NOP} which is used to
308 represent the various @code{END} statements if they carry a label.
310 filled in. Fields that are generally applicable are the @code{next}
311 and @code{here} fields. The former points to the next statement in
312 the current block or is @code{NULL} if the current statement is the
313 last in a block, @code{here} points to the statement label of the
316 If the current statement is one of @code{IF}, @code{DO}, @code{SELECT}
318 represent this, the @code{block} member is set to point to a
319 @code{gfc_code} structure whose @code{next} member starts the chain of
320 statements inside the block; this structure's @code{op} member should be set to
321 the same value as the parent structure's @code{op} member. The @code{SELECT}
322 and @code{IF} statements may contain various blocks (the chain of @code{ELSE IF}
323 and @code{ELSE} blocks or the various @code{CASE}s, respectively). These chains
324 are linked-lists formed by the @code{block} members.
326 Consider the following example code:
341 follows, were the horizontal link-chains are those induced by the @code{next}
342 members and vertical links down are those of @code{block}. @samp{==|} and
343 @samp{--|} mean @code{NULL} pointers to mark the end of a chain:
360 Conditionals are represented by @code{gfc_code} structures with their
361 @code{op} member set to @code{EXEC_IF}. This structure's @code{block}
362 member must point to another @code{gfc_code} node that is the header of the
363 if-block. This header's @code{op} member must be set to @code{EXEC_IF}, too,
364 its @code{expr} member holds the condition to check for, and its @code{next}
365 should point to the code-chain of the statements to execute if the condition is
368 If in addition an @code{ELSEIF} or @code{ELSE} block is present, the
369 @code{block} member of the if-block-header node points to yet another
370 @code{gfc_code} structure that is the header of the elseif- or else-block. Its
372 @code{ELSE} block without a new condition the @code{expr} member should be
373 @code{NULL}. This block can itself have its @code{block} member point to the
374 next @code{ELSEIF} or @code{ELSE} block if there's a chain of them.
379 @code{DO} loops are stored in the tree as @code{gfc_code} nodes with their
380 @code{op} set to @code{EXEC_DO} for a @code{DO} loop with iterator variable and
381 to @code{EXEC_DO_WHILE} for infinite @code{DO}s and @code{DO WHILE} blocks.
382 Their @code{block} member should point to a @code{gfc_code} structure heading
383 the code-chain of the loop body; its @code{op} member should be set to
384 @code{EXEC_DO} or @code{EXEC_DO_WHILE}, too, respectively.
386 For @code{DO WHILE} loops, the loop condition is stored on the top
387 @code{gfc_code} structure's @code{expr} member; @code{DO} forever loops are
388 simply @code{DO WHILE} loops with a constant @code{.TRUE.} loop condition in
391 Similarly, @code{DO} loops with an iterator have instead of the condition their
392 @code{ext.iterator} member set to the correct values for the loop iterator
396 @subsection @code{SELECT} Statements
398 A @code{SELECT} block is introduced by a @code{gfc_code} structure with an
399 @code{op} member of @code{EXEC_SELECT} and @code{expr} containing the expression
400 to evaluate and test. Its @code{block} member starts a list of @code{gfc_code}
401 structures linked together by their @code{block} members that stores the various
402 @code{CASE} parts.
404 Each @code{CASE} node has its @code{op} member set to @code{EXEC_SELECT}, too,
405 its @code{next} member points to the code-chain to be executed in the current
406 case-block, and @code{extx.case_list} contains the case-values this block
407 corresponds to. The @code{block} member links to the next case in the list.
410 @subsection @code{BLOCK} and @code{ASSOCIATE}
412 The code related to a @code{BLOCK} statement is stored inside an
413 @code{gfc_code} structure (say @var{c})
414 with @code{c.op} set to @code{EXEC_BLOCK}. The
415 @code{gfc_namespace} holding the locally defined variables of the
416 @code{BLOCK} is stored in @code{c.ext.block.ns}. The code inside the
417 construct is in @code{c.code}.
419 @code{ASSOCIATE} constructs are based on @code{BLOCK} and thus also have
420 the internal storage structure described above (including @code{EXEC_BLOCK}).
421 However, for them @code{c.ext.block.assoc} is set additionally and points
422 to a linked list of @code{gfc_association_list} structures. Those
424 The associate-names themselves are still also added to the @code{BLOCK}'s
425 namespace as ordinary symbols, but they have their @code{gfc_symbol}'s
426 member @code{assoc} set also pointing to the association-list structure.
431 of the @code{BLOCK} construct assignments are automatically generated to
441 @section @code{gfc_expr}
442 @tindex @code{gfc_expr}
443 @tindex @code{struct gfc_expr}
448 @code{gfc_expr} objects. The member @code{expr_type} specifies the overall
449 type of an expression (for instance, @code{EXPR_CONSTANT} for constants or
450 @code{EXPR_VARIABLE} for variable references). The members @code{ts} and
451 @code{rank} as well as @code{shape}, which can be @code{NULL}, specify
453 tree of which the current structure is the root. @code{where} is the locus of
454 this expression in the source code.
457 (that is, the value of its @code{expr_type} member), the corresponding structure
458 in the @code{value} union will usually contain additional data describing the
459 expression's value in a type-specific manner. The @code{ref} member is used to
466 Scalar constants are represented by @code{gfc_expr} nodes with their
467 @code{expr_type} set to @code{EXPR_CONSTANT}. The constant's value shall
468 already be known at compile-time and is stored in the @code{logical},
469 @code{integer}, @code{real}, @code{complex} or @code{character} struct inside
470 @code{value}, depending on the constant's type specification.
476 some operator on one or two operands. The expressions have an @code{expr_type}
477 of @code{EXPR_OP}. Their @code{value.op} structure contains additional data.
479 @code{op1} and optionally @code{op2} if the operator is binary point to the
480 two operands, and @code{operator} or @code{uop} describe the operator that
481 should be evaluated on these operands, where @code{uop} describes a user-defined
487 If the expression is the return value of a function-call, its @code{expr_type}
488 is set to @code{EXPR_FUNCTION}, and @code{symtree} must point to the symtree
489 identifying the function to be called. @code{value.function.actual} holds the
491 @code{gfc_actual_arglist} nodes.
493 The other members of @code{value.function} describe the function being called
497 structure's @code{symtree} member.
500 procedures; those have the @code{expr_type} @code{EXPR_COMPCALL} with
501 @code{value.compcall} containing the argument list and the procedure called,
502 while @code{symtree} and @code{ref} describe the object on which the procedure
503 was called in the same way as a @code{EXPR_VARIABLE} expression would.
510 ``derived-type constants'') are @code{gfc_expr} structures with their
511 @code{expr_type} member set to @code{EXPR_ARRAY} or @code{EXPR_STRUCTURE},
512 respectively. For structure constructors, @code{symtree} points to the
516 stored as linked-list of @code{gfc_constructor} nodes in the
517 @code{value.constructor} member.
522 @code{NULL} is a special value for pointers; it can be of different base types.
523 Such a @code{NULL} value is represented in the internal tree by a
524 @code{gfc_expr} node with @code{expr_type} @code{EXPR_NULL}. If the base type
525 of the @code{NULL} expression is known, it is stored in @code{ts} (that's for
526 instance the case for default-initializers of @code{ALLOCATABLE} components),
527 but this member can also be set to @code{BT_UNKNOWN} if the information is not
529 @code{NULL()}).
534 Variable references are @code{gfc_expr} structures with their @code{expr_type}
535 set to @code{EXPR_VARIABLE}; their @code{symtree} should point to the variable
540 @samp{struct%component(2:5)}, where @code{component} is either an array or
541 a @code{CHARACTER} member of @code{struct} that is of some derived-type. Such a
542 chain of references is achieved by a linked list headed by @code{ref} of the
543 @code{gfc_expr} node. For the example above it would be (@samp{==|} is the
544 last @code{NULL} pointer):
550 If @code{component} is a string rather than an array, the last element would be
551 a @code{REF_SUBSTRING} reference, of course. If the variable itself or some
554 @code{REF_ARRAY} reference must be built as the last element in the chain with
555 an array-reference type of @code{AR_FULL}. Consider this example code:
568 The @code{gfc_expr} nodes representing the arguments to the @samp{do_something}
579 @code{EXPR_SUBSTRING} is a special type of expression that encodes a substring
580 reference of a constant string, as in the following code snippet:
586 In this case, @code{value.character} contains the full string's data as if it
587 was a string constant, but the @code{ref} member is also set and points to a
610 Type-bound procedures are stored in the @code{tb_sym_root} of the namespace
611 @code{f2k_derived} associated with the derived-type symbol as @code{gfc_symtree}
616 In addition, this type of symtrees stores in @code{n.tb} a struct of type
617 @code{gfc_typebound_proc} containing the additional data needed: The
618 binding attributes (like @code{PASS} and @code{NOPASS}, @code{NON_OVERRIDABLE}
620 overrides or extends an inherited binding of the same name, @code{overridden}
621 points to this binding's @code{gfc_typebound_proc} structure.
627 For specific bindings (declared with @code{PROCEDURE}), if they have a
630 and its position remembered as @code{pass_arg_num} in @code{gfc_typebound_proc}.
631 The binding's target procedure is pointed-to by @code{u.specific}.
633 @code{DEFERRED} bindings are just like ordinary specific bindings, except
634 that their @code{deferred} flag is set of course and that @code{u.specific}
643 be extended to allow special code generation during the trans-phase to dispatch
650 Bindings declared as @code{GENERIC} store the specific bindings they target as
651 a linked list using nodes of type @code{gfc_tbp_generic} in @code{u.generic}.
653 this symtree is bound to the corresponding @code{gfc_typebound_proc} structure
658 and the call's target procedure (@code{value.compcall.tbp}) is re-pointed to
666 Calls to type-bound procedures are stored in the parse-tree as @code{gfc_expr}
667 nodes of type @code{EXPR_COMPCALL}. Their @code{value.compcall.actual} saves
668 the actual argument list of the call and @code{value.compcall.tbp} points to the
669 @code{gfc_typebound_proc} structure of the binding to be called. The object
671 @code{symtree} and @code{ref}, as if the expression was of type
672 @code{EXPR_VARIABLE}.
674 For code like this:
679 the @code{CALL} is represented in the parse-tree as a @code{gfc_code} node of
680 type @code{EXEC_COMPCALL}. The @code{expr} member of this node holds an
681 expression of type @code{EXPR_COMPCALL} of the same structure as mentioned above
682 except that its target procedure is of course a @code{SUBROUTINE} and not a
683 @code{FUNCTION}.
687 @code{value.compcall.ignore_pass} signals that even though a @code{PASS}
690 @code{value.compcall.base_object} overrides, if it is set, the base-object
691 (that is normally stored in @code{symtree} and @code{ref} as mentioned above);
693 need not be of type @code{EXPR_VARIABLE} and thus representable in this way.
694 Finally, if @code{value.compcall.assign} is set, the call was produced in
705 Type-bound operators are in fact basically just @code{GENERIC} procedure
710 User-defined operators (like @code{.MYOPERATOR.})
711 are stored in the @code{f2k_derived} namespace's @code{tb_uop_root}
713 @code{tb_sym_root}; their symtrees' names are the operator-names (e.g.
716 array member @code{tb_op} indexed by the intrinsic operator's enum
717 value. Those need not be packed into @code{gfc_symtree} structures and are
718 only @code{gfc_typebound_proc} instances.
725 operator call is replaced with an internally generated @code{GENERIC}
756 The basic data structure of GENERIC is a @code{tree}. Everything in
757 GENERIC is a @code{tree}, including types and statements. Fortunately
758 for the gfortran programmer, @code{tree} variables are
762 @code{tree} expressions are built using functions such as, for
763 example, @code{fold_build2_loc}. For two tree variables @code{a} and
764 @code{b}, both of which have the type @code{gfc_arry_index_type},
765 calculation @code{c = a * b} would be done by
774 using @code{fold_convert}.
776 Accessing individual members in the @code{tree} structures should not
779 One basic data structure is the @code{stmtblock_t} struct. This is
780 used for holding a list of statements, expressed as @code{tree}
781 expressions. If a block is created using @code{gfc_start_block}, it
783 @code{gfc_init_block}, it does not have its own scope.
788 @code{gfc_add_expr_to_block}
790 @code{void gfc_prepend_expr_to_block}
791 @item Make a block into a single @code{tree} using
792 @code{gfc_finish_block}. For example, this is needed to put the
793 contents of a block into the @code{if} or @code{else} branch of
794 a @code{COND_EXPR}.
797 Variables are also @code{tree} expressions, they can be created using
798 @code{gfc_create_var}. Assigning to a variable can be done with
799 @code{gfc_add_modify}.
802 scope with the prefix ``everything'' in the @code{stmt_block}
803 @code{block} and assigning the value 42 would be
815 Converting expressions to @code{tree} is done by functions called
816 @code{gfc_conv_*}.
819 @code{gfc_se} structure. Its @code{expr} member is a @code{tree} that
820 holds the value of the expression. A @code{gfc_se} structure is
821 initialized using @code{gfc_init_se}; it needs to be embedded in an
822 outer @code{gfc_se}.
825 and after evaluation of the expression, for example code for the
827 Therefore, @code{gfc_se} contains the members @code{pre} and
828 @code{post}, which point to @code{stmt_block} blocks for code that
831 When using a local @code{gfc_se} to convert some expression, it is
832 often necessary to add the generated @code{pre} and @code{post} blocks
833 to the @code{pre} or @code{post} blocks of the outer @code{gfc_se}.
848 Conversion functions which need a @code{gfc_se} structure will have a
851 @code{gfc_se} also contains pointers to a @code{gfc_ss} and a
852 @code{gfc_loopinfo} structure. These are needed by the scalarizer.
856 Translating statements to @code{tree} is done by functions called
857 @code{gfc_trans_*}. These functions usually get passed a
858 @code{gfc_code} structure, evaluate any expressions and then
859 return a @code{tree} structure.
864 @code{gfc_symbol}, @code{gfc_charlen} and other front-end structures
865 contain a @code{backend_decl} variable, which contains the @code{tree}
869 @code{gfc_get*}.
918 defined, e.g., if one adds a new symbols @code{foo} and @code{bar} to
929 where @code{GFORTRAN_1.0} is the version node of the current release,
930 and @code{GFORTRAN_1.1} is the version node of the next release where
943 In this example, @code{foo@@} represents the symbol @code{foo} bound to
945 contains this example would define 4 C functions: @code{original_foo},
946 @code{old_foo}, @code{old_foo1}, and @code{new_foo}.
948 In this case the map file must contain @code{foo} in @code{VERS_1.1}
949 and @code{VERS_1.2} as well as in @code{VERS_2.0}.