tree.def

gcc库的原代码,对编程有很大帮助.

   Its meaning is defined by the language front end.
   layout_type does not know how to lay this out,
   so the front-end must do so manually.  */
DEFTREECODE (LANG_TYPE, "lang_type", "t", 0)

/* Expressions */

/* First, the constants.  */

/* Contents are in TREE_INT_CST_LOW and TREE_INT_CST_HIGH fields,
   32 bits each, giving us a 64 bit constant capability.
   Note: constants of type char in Pascal are INTEGER_CST,
   and so are pointer constants such as nil in Pascal or NULL in C.
   `(int *) 1' in C also results in an INTEGER_CST.  */
DEFTREECODE (INTEGER_CST, "integer_cst", "c", 2)

/* Contents are in TREE_REAL_CST field.  Also there is TREE_CST_RTL.  */
DEFTREECODE (REAL_CST, "real_cst", "c", 3)

/* Contents are in TREE_REALPART and TREE_IMAGPART fields,
   whose contents are other constant nodes.
   Also there is TREE_CST_RTL.  */
DEFTREECODE (COMPLEX_CST, "complex_cst", "c", 3)

/* Contents are TREE_STRING_LENGTH and TREE_STRING_POINTER fields.
   Also there is TREE_CST_RTL.  */
DEFTREECODE (STRING_CST, "string_cst", "c", 3)

/* Declarations.  All references to names are represented as ..._DECL nodes.
   The decls in one binding context are chained through the TREE_CHAIN field.
   Each DECL has a DECL_NAME field which contains an IDENTIFIER_NODE.
    (Some decls, most often labels, may have zero as the DECL_NAME).
   DECL_CONTEXT points to the node representing the context in which
    this declaration has its scope.  For FIELD_DECLs, this is the
    RECORD_TYPE, UNION_TYPE, or QUAL_UNION_TYPE node that the field
    is a member of.  For VAR_DECL, PARM_DECL, FUNCTION_DECL, LABEL_DECL,
    and CONST_DECL nodes, this points to the FUNCTION_DECL for the
    containing function, or else yields NULL_TREE if the given decl
    has "file scope".
   DECL_ABSTRACT_ORIGIN, if non-NULL, points to the original (abstract)
    ..._DECL node of which this decl is an (inlined or template expanded)
    instance.
   The TREE_TYPE field holds the data type of the object, when relevant.
    LABEL_DECLs have no data type.  For TYPE_DECL, the TREE_TYPE field
    contents are the type whose name is being declared.
   The DECL_ALIGN, DECL_SIZE,
    and DECL_MODE fields exist in decl nodes just as in type nodes.
    They are unused in LABEL_DECL, TYPE_DECL and CONST_DECL nodes.

   DECL_OFFSET holds an integer number of bits offset for the location.
   DECL_VOFFSET holds an expression for a variable offset; it is
   to be multiplied by DECL_VOFFSET_UNIT (an integer).
   These fields are relevant only in FIELD_DECLs and PARM_DECLs.

   DECL_INITIAL holds the value to initialize a variable to,
   or the value of a constant.  For a function, it holds the body
   (a node of type BLOCK representing the function's binding contour
   and whose body contains the function's statements.)  For a LABEL_DECL
   in C, it is a flag, nonzero if the label's definition has been seen.

   PARM_DECLs use a special field:
   DECL_ARG_TYPE is the type in which the argument is actually
    passed, which may be different from its type within the function.

   FUNCTION_DECLs use four special fields:
   DECL_ARGUMENTS holds a chain of PARM_DECL nodes for the arguments.
   DECL_RESULT holds a RESULT_DECL node for the value of a function,
    or it is 0 for a function that returns no value.
    (C functions returning void have zero here.)
   DECL_RESULT_TYPE holds the type in which the result is actually
    returned.  This is usually the same as the type of DECL_RESULT,
    but (1) it may be a wider integer type and
    (2) it remains valid, for the sake of inlining, even after the
    function's compilation is done.
   DECL_FUNCTION_CODE is a code number that is nonzero for
    built-in functions.  Its value is an enum built_in_function
    that says which built-in function it is.

   DECL_SOURCE_FILE holds a filename string and DECL_SOURCE_LINE
   holds a line number.  In some cases these can be the location of
   a reference, if no definition has been seen.

   DECL_ABSTRACT is non-zero if the decl represents an abstract instance
   of a decl (i.e. one which is nested within an abstract instance of a
   inline function.  */

DEFTREECODE (FUNCTION_DECL, "function_decl", "d", 0)
DEFTREECODE (LABEL_DECL, "label_decl", "d", 0)
DEFTREECODE (CONST_DECL, "const_decl", "d", 0)
DEFTREECODE (TYPE_DECL, "type_decl", "d", 0)
DEFTREECODE (VAR_DECL, "var_decl", "d", 0)
DEFTREECODE (PARM_DECL, "parm_decl", "d", 0)
DEFTREECODE (RESULT_DECL, "result_decl", "d", 0)
DEFTREECODE (FIELD_DECL, "field_decl", "d", 0)

/* References to storage.  */

/* Value is structure or union component.
   Operand 0 is the structure or union (an expression);
   operand 1 is the field (a node of type FIELD_DECL).  */
DEFTREECODE (COMPONENT_REF, "component_ref", "r", 2)

/* Reference to a group of bits within an object.  Similar to COMPONENT_REF
   except the position is given explicitly rather than via a FIELD_DECL.
   Operand 0 is the structure or union expression;
   operand 1 is a tree giving the number of bits being referenced;
   operand 2 is a tree giving the position of the first referenced bit.
   The field can be either a signed or unsigned field;
   TREE_UNSIGNED says which.  */
DEFTREECODE (BIT_FIELD_REF, "bit_field_ref", "r", 3)
   
/* C unary `*' or Pascal `^'.  One operand, an expression for a pointer.  */
DEFTREECODE (INDIRECT_REF, "indirect_ref", "r", 1)

/* Reference to the contents of an offset
   (a value whose type is an OFFSET_TYPE).
   Operand 0 is the object within which the offset is taken.
   Operand 1 is the offset.  */
DEFTREECODE (OFFSET_REF, "offset_ref", "r", 2)

/* Pascal `^` on a file.  One operand, an expression for the file.  */
DEFTREECODE (BUFFER_REF, "buffer_ref", "r", 1)

/* Array indexing in languages other than C.
   Operand 0 is the array; operand 1 is a list of indices
   stored as a chain of TREE_LIST nodes.  */
DEFTREECODE (ARRAY_REF, "array_ref", "r", 2)

/* Constructor: return an aggregate value made from specified components.
   In C, this is used only for structure and array initializers.
   The first "operand" is really a pointer to the RTL,
   for constant constructors only.
   The second operand is a list of component values
   made out of a chain of TREE_LIST nodes.  */
DEFTREECODE (CONSTRUCTOR, "constructor", "e", 2)

/* The expression types are mostly straightforward,
   with the fourth argument of DEFTREECODE saying
   how many operands there are.
   Unless otherwise specified, the operands are expressions.  */

/* Contains two expressions to compute, one followed by the other.
   the first value is ignored.  The second one's value is used.  */
DEFTREECODE (COMPOUND_EXPR, "compound_expr", "e", 2)

/* Assignment expression.  Operand 0 is the what to set; 1, the new value.  */
DEFTREECODE (MODIFY_EXPR, "modify_expr", "e", 2)

/* Initialization expression.  Operand 0 is the variable to initialize;
   Operand 1 is the initializer.  */
DEFTREECODE (INIT_EXPR, "init_expr", "e", 2)

/* For TARGET_EXPR, operand 0 is the target of an initialization,
   operand 1 is the initializer for the target,
   and operand 2 is the cleanup for this node, if any.  */
DEFTREECODE (TARGET_EXPR, "target_expr", "e", 3)

/* Conditional expression ( ... ? ... : ...  in C).
   Operand 0 is the condition.
   Operand 1 is the then-value.
   Operand 2 is the else-value.  */
DEFTREECODE (COND_EXPR, "cond_expr", "e", 3)

/* Declare local variables, including making RTL and allocating space.
   Operand 0 is a chain of VAR_DECL nodes for the variables.
   Operand 1 is the body, the expression to be computed using 
   the variables.  The value of operand 1 becomes that of the BIND_EXPR.
   Operand 2 is the BLOCK that corresponds to these bindings
   for debugging purposes.  If this BIND_EXPR is actually expanded,
   that sets the TREE_USED flag in the BLOCK.

   The BIND_EXPR is not responsible for informing parsers
   about these variables.  If the body is coming from the input file,
   then the code that creates the BIND_EXPR is also responsible for 
   informing the parser of the variables.

   If the BIND_EXPR is ever expanded, its TREE_USED flag is set.
   This tells the code for debugging symbol tables not to ignore the BIND_EXPR.
   If the BIND_EXPR should be output for debugging but will not be expanded, 
   set the TREE_USED flag by hand.

   In order for the BIND_EXPR to be known at all, the code that creates it
   must also install it as a subblock in the tree of BLOCK
   nodes for the function.  */
DEFTREECODE (BIND_EXPR, "bind_expr", "e", 3)

/* Function call.  Operand 0 is the function.
   Operand 1 is the argument list, a list of expressions
   made out of a chain of TREE_LIST nodes.
   There is no operand 2.  That slot is used for the
   CALL_EXPR_RTL macro (see preexpand_calls).  */
DEFTREECODE (CALL_EXPR, "call_expr", "e", 3)

/* Call a method.  Operand 0 is the method, whose type is a METHOD_TYPE.
   Operand 1 is the expression for "self".
   Operand 2 is the list of explicit arguments.  */
DEFTREECODE (METHOD_CALL_EXPR, "method_call_expr", "e", 4)

/* Specify a value to compute along with its corresponding cleanup.
   Operand 0 argument is an expression whose value needs a cleanup.
   Operand 1 is an RTL_EXPR which will eventually represent that value.
   Operand 2 is the cleanup expression for the object.
     The RTL_EXPR is used in this expression, which is how the expression
     manages to act on the proper value.
   The cleanup is executed by the first enclosing CLEANUP_POINT_EXPR, if
   it exists, otherwise it is the responsibility of the caller to manually
   call expand_cleanups_to, as needed.  */
DEFTREECODE (WITH_CLEANUP_EXPR, "with_cleanup_expr", "e", 3)

/* Specify a cleanup point.
   Operand 0 is an expression that may have cleanups.  If it does, those
   cleanups are executed after the expression is expanded.

   Note that if the expression is a reference to storage, it is forced out
   of memory before the cleanups are run.  This is necessary to handle
   cases where the cleanups modify the storage referenced; in the
   expression 't.i', if 't' is a struct with an integer member 'i' and a
   cleanup which modifies 'i', the value of the expression depends on
   whether the cleanup is run before or after 't.i' is evaluated.  When
   expand_expr is run on 't.i', it returns a MEM.  This is not good enough;
   the value of 't.i' must be forced out of memory.

   As a consequence, the operand of a CLEANUP_POINT_EXPR must not have
   BLKmode, because it will not be forced out of memory.  */
DEFTREECODE (CLEANUP_POINT_EXPR, "cleanup_point_expr", "e", 1)

/* The following two codes are used in languages that have types where
   the position and/or sizes of fields vary from object to object of the
   same type, i.e., where some other field in the object contains a value
   that is used in the computation of another field's offset or size.

   For example, a record type with a discriminant in Ada is such a type.
   This mechanism is also used to create "fat pointers" for unconstrained
   array types in Ada; the fat pointer is a structure one of whose fields is
   a pointer to the actual array type and the other field is a pointer to a
   template, which is a structure containing the bounds of the array.  The
   bounds in the type pointed to by the first field in the fat pointer refer