![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to g++int.texi CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [GCC 2.x] / gcc|
Return to g++int.texi CVS log | Up to [GCC 2.x] / gcc |
1.1 root 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 [email protected].
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
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.