home *** CD-ROM | disk | FTP | other *** search
/ OS/2 Professional / OS2PRO194.ISO / os2 / prgramer / unix / emx / gnu / doc / gppint.tex < prev    next >
Encoding:
Text File  |  1992-08-04  |  8.1 KB  |  241 lines

  1. @node internals
  2. @chapter Internal Architecture of the Compiler
  3.  
  4. This is meant to describe the C++ frontend for gcc in detail.
  5. Questions and comments to mrs@cygnus.com.
  6.  
  7. @index delete, two argument
  8. For two argument delete, the second argument is always calculated by
  9. ``virtual_size ='' in the source.  It currently has a problem, in that
  10. object size is not calculated by the virtual destructor and passed back
  11. for the second parameter to delete.  Destructors need to return a value
  12. just like constructors.
  13.  
  14. @index visibility checking
  15. Visibility checking in general is unimplemented, there are a few cases
  16. where it is implemented.  grok_enum_decls should be used in more places
  17. to do visibility checking, but this is only the tip of a bigger problem.
  18.  
  19. @index volatile
  20. volatile is not implemented in general.
  21.  
  22. @index const
  23. const is completely implemented except for function overload selection.
  24.  
  25. @index protected base classes
  26. Protected base classes are not fully implemented.
  27.  
  28. @item BLOCK_SUPERCONTEXT
  29. In the outermost scope of each function, it points to the FUNCTION_DECL
  30. node.  It aids in better DWARF support of inline functions.
  31.  
  32. @item DECL_CLASS_CONTEXT
  33. Identifys the context that the _DECL was found in.
  34.  
  35. Has values of:
  36.  
  37.     RECORD_TYPE, or UNION_TYPE.
  38.  
  39. What things can this be used on:
  40.  
  41.     TYPE_DECLs, *_DECLs
  42.  
  43. @item DECL_NESTED_TYPENAME
  44. Holds the fully qualified type name.  Example, Base::Derived.
  45.  
  46. Has values of:
  47.  
  48.     IDENTIFIER_NODE
  49.  
  50. What things can this be used on:
  51.  
  52.     TYPE_DECLs
  53.  
  54. @item TYPE_NAME
  55. Names the type.
  56.  
  57. Has values of:
  58.  
  59.     0 for things that don't have names.
  60.     should be IDENTIFIER_NODE for RECORD_TYPEs UNION_TYPEs and ENUM_TYPEs.
  61.     TYPE_DECL for RECORD_TYPEs, UNION_TYPEs and ENUM_TYPEs, but shouldn't
  62.         be.
  63.     TYPE_DECL for typedefs, unsure why.
  64.  
  65. What things can one use this on:
  66.  
  67.     TYPE_DECLs
  68.     RECORD_TYPEs
  69.     UNION_TYPEs
  70.     ENUM_TYPEs
  71.  
  72. How is it used:
  73.  
  74.     Used by dwarfout.c to fetch the name of structs, unoins and enums
  75.     to create AT_name fields.
  76.  
  77. History:
  78.  
  79.     It currently points to the TYPE_DECL for RECORD_TYPEs,
  80.     UNION_TYPEs and ENUM_TYPEs, but it should be history soon.
  81.  
  82. @item DECL_NAME
  83.  
  84. Has values of:
  85.  
  86.     0 for things that don't have names.
  87.     IDENTIFIER_NODE for TYPE_DECLs.
  88.  
  89. @item TYPE_DECL
  90. Used to represent typedefs, and used to represent bindings layers.
  91.  
  92. Components:
  93.  
  94.     DECL_NAME is the name of the typedef.  For example, foo would
  95.     be found in the DECL_NAME slot when @code{typedef int foo;} is
  96.     seen.
  97.  
  98.     DECL_SOURCE_LINE identifies what source line number in the
  99.     source file the declaration was found at.  A value of 0
  100.     indicates that this TYPE_DECL is just an internal binding layer
  101.     marker, and does not correspond to a user suppiled typedef.
  102.  
  103.     DECL_SOURCE_FILE @xref{DECL_SOURCE_FILE}.
  104.  
  105. @item DECL_IGNORED_P
  106. A bit that can be set to inform the debug information output routines in
  107. the backend that a certain _DECL node should be totally ignored.
  108.  
  109. Used in cases where it is known that the debugging information will be
  110. output in another file, or where a sub-type is known not to be needed
  111. because the enclosing type is not needed.
  112.  
  113. A compiler constructed virtual destructor in derived classes that do not
  114. define an exlicit destructor that was defined exlicit in a base class
  115. has this bit set as well.  Also used on __FUNCTION__ and
  116. __PRETTY_FUNCTION__ to mark they are ``compiler generated.''  c-decl and
  117. c-lex.c both want DECL_IGNORED_P set for ``internally generated vars,''
  118. and ``user-invisible variable.''
  119.  
  120. Functions built by the C++ front-end such as default destructors,
  121. virtual desctructors and default constructors want to be marked that
  122. they are compiler generated, but unsure why.
  123.  
  124. Currently, it is used in an absolute way in the C++ front-end, as an
  125. optimization, to tell the debug information output routines to not
  126. generate debugging information that will be output by another separately
  127. compiled file.
  128.  
  129. @findex DECL_SOURCE_FILE
  130. @item DECL_SOURCE_FILE
  131. Identifies what source file a particular declaration was found in.
  132.  
  133. Has values of:
  134.  
  135.     "<built-in>" on TYPE_DECLs to mean the typedef is built in.
  136.  
  137. @item DECL_SOURCE_LINE
  138. Identifies what source line number in the source file the declaration
  139. was found at.
  140.  
  141. Has values of:
  142.  
  143.     0 for an undefined label.
  144.  
  145.     0 for TYPE_DECLs that are internally generated.
  146.  
  147.     0 for FUNCTION_DECLs for functions generated by the compiler.
  148.         (not yet, but should be.)
  149.  
  150. @item DECL_VIRTUAL_P
  151. A flag used on FIELD_DECLs and VAR_DECLs.  (Documentation in tree.h is
  152. wrong.)  Used in VAR_DECLs to indicate that the variable is a vtable.
  153. It is also used in FIELD_DECLs for vtable pointers.
  154.  
  155. What things can this be used on:
  156.  
  157.     FIELD_DECLs and VAR_DECLs.
  158.  
  159. @item DECL_VINDEX
  160. Used for FUNCTION_DECLs in two different ways.  Before the structure
  161. containing the FUNCTION_DECL is laid out, DECL_VINDEX may point to a
  162. FUNCTION_DECL in a base class which is the FUNCTION_DECL which this
  163. FUNCTION_DECL will replace as a virtual function.  When the class is
  164. laid out, this pointer is changed to an INTEGER_CST node which is
  165. suitable for use as an index into the virtual function table.
  166.  
  167. DECL_VINDEX may be a TREE_LIST, that would seem to be a list of
  168. overridden FUNCTION_DECLs.  add_virtual_function has code to deal with
  169. this when it uses the variable base_fndecl_list, but it would seem that
  170. somehow, it is possible for the TREE_LIST to pursist until method_call,
  171. and it should not.
  172.  
  173. @item TREE_USED
  174.  
  175. Has values of:
  176.  
  177.     0 for unused labels.
  178.  
  179. @item TREE_ADDRESSABLE
  180. A flag that is set for any type that has a constructor.
  181.  
  182. @item CLASSTYPE_METHOD_VEC
  183. The following is true after finish_struct has been called (on the
  184. class?) but not before.  Before finish_struct is called, things are
  185. different to some extent.  Contains a TREE_VEC of methods of the class.
  186. The TREE_VEC_LENGTH is the number of differently named methods plus one
  187. for the 0th entry.  The 0th entry is always allocated, and reserved for
  188. ctors and dtors.  If there are none, TREE_VEC_ELT(N,0) == NULL_TREE.
  189. Each entry of the TREE_VEC is a FUNCTION_DECL.  For each FUNCTION_DECL,
  190. there is a DECL_CHAIN slot.  If the FUNCTION_DECL is the last one with a
  191. given name, the DECL_CHAIN slot is NULL_TREE.  Otherwise it is the next
  192. method that has the same name (but a different signature).  It would
  193. seem that it is not true that because the DECL_CHAIN slot is used in
  194. this way, we cannot call pushdecl to put the method in the global scope
  195. (cause that would overwrite the TREE_CHAIN slot), because they use
  196. different _CHAINs.
  197.  
  198. friends are kept in TREE_LISTs, so that there's no need to use their
  199. TREE_CHAIN slot for anything.
  200.  
  201. Has values of:
  202.  
  203.     TREE_VEC
  204.     
  205. @item TYPE_METHOD
  206. Related to CLASSTYPE_METHOD_VEC.  Chained together with TREE_CHAIN.
  207. dbxout.c uses this to get at the methods of a class.
  208.  
  209. @item CLASSTYPE_TAGS
  210. CLASSTYPE_TAGS is a linked (via TREE_CHAIN) list of member classes of a
  211. class. TREE_PURPOSE is the name, TREE_VALUE is the type (pushclass scans
  212. these and calls pushtag on them.)
  213.  
  214. finish_struct scans these to produce TYPE_DECLs to add to the
  215. TYPE_FIELDS of the type.
  216.  
  217. It is expected that name found in the TREE_PURPOSE slot is unique,
  218. resolve_scope_to_name is one such place that depends upon this
  219. uniqueness.
  220.  
  221. @item TYPE_FIELDS
  222. TYPE_FIELDS is a linked list (via TREE_CHAIN) of member types of a
  223. class.  The list can contain TYPE_DECLs, but there can also be other
  224. things in the list apparently.  See also CLASSTYPE_TAGS.
  225.  
  226. @item TREE_PRIVATE
  227. Set for FIELD_DECLs by finish_struct.  But not uniformly set.
  228.  
  229. The following routines do something with PRIVATE visibility:
  230. build_method_call, alter_visibility, finish_struct_methods,
  231. finish_struct, convert_to_aggr, CWriteLanguageDecl, CWriteLanguageType,
  232. CWriteUseObject, compute_visibility, lookup_field, dfs_pushdecl,
  233. GNU_xref_member, dbxout_type_fields, dbxout_type_method_1
  234.  
  235. @item TREE_PROTECTED
  236. The following routines do something with PROTECTED visibility:
  237. build_method_call, alter_visibility, finish_struct, convert_to_aggr,
  238. CWriteLanguageDecl, CWriteLanguageType, CWriteUseObject,
  239. compute_visibility, lookup_field, GNU_xref_member, dbxout_type_fields,
  240. dbxout_type_method_1
  241.