![[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:
1.1.1.2 ! root 7: @section Limitations of g++
! 8: @node Limitations of g++
! 9:
! 10: @index pushdecl_class_level
! 11: I suspect there are other uses of pushdecl_class_level that do not call
! 12: set_identifier_type_value in tandem with the call to
! 13: pushdecl_class_level. It would seem to be an omission.
! 14:
1.1 root 15: @index delete, two argument
16: For two argument delete, the second argument is always calculated by
17: ``virtual_size ='' in the source. It currently has a problem, in that
18: object size is not calculated by the virtual destructor and passed back
19: for the second parameter to delete. Destructors need to return a value
1.1.1.2 ! root 20: just like constructors. ANSI C++ Jun 5 92 wp 12.5.6
! 21:
! 22: The second argument is magically deleted in build_method_call, if it is
! 23: not used. It needs to be deleted for global operator delete also.
1.1 root 24:
25: @index visibility checking
26: Visibility checking in general is unimplemented, there are a few cases
27: where it is implemented. grok_enum_decls should be used in more places
28: to do visibility checking, but this is only the tip of a bigger problem.
29:
30: @index volatile
31: volatile is not implemented in general.
32:
33: @index const
34: const is completely implemented except for function overload selection.
1.1.1.2 ! root 35: Overload function selection is getting better with respect to const.
! 36:
! 37: @index pointers to members
! 38: Pointers to members are only minimally supported, and there are places
! 39: where the grammar doesn't even properly accept them yet.
! 40:
! 41: @node Routines
! 42: @section Routines
! 43:
! 44: This section describes some of the routines used in the C++ front-end.
! 45:
! 46: build_vtable and prepare_fresh_vtable is used only within the cp-class.c
! 47: file, and only in finish_struct and modify_vtable_entries.
! 48:
! 49: build_vtable, prepare_fresh_vtable, and finish_struct are the only
! 50: routines that set DECL_VPARENT.
! 51:
! 52: finish_struct can steal the virtual function table from parents, this
! 53: prohibits related_vslot from working. When finish_struct steals, we
! 54: know that get_binfo (DECL_FIELD_CONTEXT (CLASSTYPE_VFIELD (t)), t, 0)
! 55: will get the related binfo.
! 56:
! 57: layout_basetypes does something with the VIRTUALS.
! 58:
! 59: Supposedly (according to Tiemann) most of the breadth first searching
! 60: done, like in get_base_distance and in get_binfo was not because of any
! 61: design decision. I have since found out the at least one part of the
! 62: compiler needs the notion of depth first binfo searching, I am going to
! 63: try and convert the whole thing, it should just work. The term
! 64: left-most refers to the depth first left-most node. It uses
! 65: MAIN_VARIENT == type as the condition to get left-most, because the
! 66: things that have BINFO_OFFSET of zero are shared and will have
! 67: themselves as their own MAIN_VARIENTs. The non-shared right ones, are
! 68: copies of the left-most one, hence if it is it's own MAIN_VARIENT, we
! 69: know it IS a left-most one, if it is not, it is a non-left-most one.
! 70:
! 71: get_base_distance's path and distance matters in it's use in:
! 72: prepare_fresh_vtable (the code is probably wrong), init_vfields depends
! 73: upon distance probably in a safe way, build_offset_ref might use partial
! 74: paths to do further lookups, hack_identifier is probably not properly
! 75: checking visibility.
! 76:
! 77: get_first_matching_virtual probably should check for get_base_distance
! 78: returning -2.
! 79:
! 80: resolve_offset_ref should be called in a more deterministic manner.
! 81: Right now, it is called in some random contexts, like for arguments at
! 82: build_method_call time, default_conversion time, convert_arguments time,
! 83: build_unary_op time, build_c_cast time, build_modify_expr time,
! 84: convert_for_assignment time, and convert_for_initialization time.
! 85:
! 86: But, there are still more contexts it needs to be called in, on was the
! 87: ever simple:
! 88:
! 89: if (obj.*pmi != 7)
! 90: ...
! 91:
! 92: Seems that the problems were due to the fact that TREE_TYPE of the
! 93: OFFSET_REF was not a OFFSET_TYPE, but rather the type of the thingy
! 94: (like INTEGER_TYPE). This problem was fixed by changing
! 95: default_conversion to check TREE_CODE (x), instead of only checking
! 96: TREE_CODE (TREE_TYPE (x)) to see if it was OFFSET_TYPE.
! 97:
! 98: @node Glossary
! 99: @section Glossary
! 100:
! 101: @item binfo
! 102: The main data structure in the compiler used to represent the
! 103: inheritance relationships between classes. The data in the binfo can be
! 104: accessed by the BINFO_ accessor macros.
! 105:
! 106: @item vtable
! 107: @item virtual function table
! 108:
! 109: The virtual function table holds information used in virtual function
! 110: dispatching. In the compiler, they are usually referred to as vtables,
! 111: or vtbls. The first index is not used in the normal way, I believe it
! 112: is probably used for the virtual destructor.
! 113:
! 114: See also vfield and virtual function table pointer.
! 115:
! 116: @item vfield
! 117:
! 118: vfields can be thought of as the base information needed to build
! 119: vtables. For every vtable that exists for a class, there is a vfield.
! 120: See also vtable and virtual function table pointer. When a type is used
! 121: as a base class to another type, the virtual function table for the
! 122: derived class can be based upon the vtable for the base class, just
! 123: extended to include the additional virtual methods declared in the
! 124: derived class.
! 125:
! 126: @item virtual function table pointer
! 127:
! 128: These are FIELD_DECLs that are pointer types that point to vtables. See
! 129: also vtable and vfield.
! 130:
! 131:
! 132: @node Macros
! 133: @section Macros
! 134:
! 135: This section describes some of the macros used on trees. The list
! 136: should be alphabetical. Eventually all macros should be documented
! 137: here. There are some postscript drawings that can be used to better
! 138: understnad from of the more complex data structures, contact Mike Stump
! 139: <[email protected]> for information about them.
! 140:
! 141:
! 142: @item BINFO_BASETYPES
! 143: A vector of additional binfos for the types inherited by this basetype.
! 144: The binfos are fully unshared (except for virtual bases, in which
! 145: case the binfo structure is shared).
! 146:
! 147: If this basetype describes type D as inherited in C,
! 148: and if the basetypes of D are E anf F,
! 149: then this vector contains binfos for inheritance of E and F by C.
! 150:
! 151: Has values of:
! 152:
! 153: TREE_VECs
! 154:
! 155:
! 156: @item BINFO_INHERITANCE_CHAIN
! 157: Temporarily used to represent specific inheritances. It usually points
! 158: to the binfo associated with the lesser derived type, but it can be
! 159: reversed by reverse_path. For example:
! 160:
! 161: Z ZbY least derived
! 162: |
! 163: Y YbX
! 164: |
! 165: X Xb most derived
! 166:
! 167: TYPE_BINFO (X) == Xb
! 168: BINFO_INHERITANCE_CHAIN (Xb) == YbX
! 169: BINFO_INHERITANCE_CHAIN (Yb) == ZbY
! 170: BINFO_INHERITANCE_CHAIN (Zb) == 0
! 171:
! 172: Not sure is the above is really true, get_base_distance has is point
! 173: towards the most derived type, opposite from above.
! 174:
! 175: Set by build_vbase_path, recursive_bounded_basetype_p,
! 176: get_base_distance, lookup_field, lookup_fnfields, and reverse_path.
! 177:
! 178: What things can this be used on:
! 179:
! 180: TREE_VECs that are binfos
! 181:
! 182:
! 183: @item BINFO_OFFSET
! 184: The offset where this basetype appears in its containing type.
! 185: BINFO_OFFSET slot holds the offset (in bytes) from the base of the
! 186: complete object to the base of the part of the object that is allocated
! 187: on behalf of this `type'. This is always 0 except when there is
! 188: multiple inheritance.
! 189:
! 190: Used on TREE_VEC_ELTs of the binfos BINFO_BASETYPES (...) for example.
! 191:
! 192:
! 193: @item BINFO_VIRTUALS
! 194: A unique list of functions for the virtual function table. See also
! 195: TYPE_BINFO_VIRTUALS.
! 196:
! 197: What things can this be used on:
! 198:
! 199: TREE_VECs that are binfos
! 200:
! 201:
! 202: @item BINFO_VTABLE
! 203: Used to find the VAR_DECL that is the virtual function table associated
! 204: with this binfo. See also TYPE_BINFO_VTABLE. To get the virtual
! 205: function table pointer, see CLASSTYPE_VFIELD.
! 206:
! 207: What things can this be used on:
! 208:
! 209: TREE_VECs that are binfos
! 210:
! 211: Has values of:
! 212:
! 213: VAR_DECLs that are virtual function tables
1.1 root 214:
215:
216: @item BLOCK_SUPERCONTEXT
217: In the outermost scope of each function, it points to the FUNCTION_DECL
218: node. It aids in better DWARF support of inline functions.
219:
1.1.1.2 ! root 220:
! 221: @item CLASSTYPE_TAGS
! 222: CLASSTYPE_TAGS is a linked (via TREE_CHAIN) list of member classes of a
! 223: class. TREE_PURPOSE is the name, TREE_VALUE is the type (pushclass scans
! 224: these and calls pushtag on them.)
! 225:
! 226: finish_struct scans these to produce TYPE_DECLs to add to the
! 227: TYPE_FIELDS of the type.
! 228:
! 229: It is expected that name found in the TREE_PURPOSE slot is unique,
! 230: resolve_scope_to_name is one such place that depends upon this
! 231: uniqueness.
! 232:
! 233:
! 234: @item CLASSTYPE_METHOD_VEC
! 235: The following is true after finish_struct has been called (on the
! 236: class?) but not before. Before finish_struct is called, things are
! 237: different to some extent. Contains a TREE_VEC of methods of the class.
! 238: The TREE_VEC_LENGTH is the number of differently named methods plus one
! 239: for the 0th entry. The 0th entry is always allocated, and reserved for
! 240: ctors and dtors. If there are none, TREE_VEC_ELT(N,0) == NULL_TREE.
! 241: Each entry of the TREE_VEC is a FUNCTION_DECL. For each FUNCTION_DECL,
! 242: there is a DECL_CHAIN slot. If the FUNCTION_DECL is the last one with a
! 243: given name, the DECL_CHAIN slot is NULL_TREE. Otherwise it is the next
! 244: method that has the same name (but a different signature). It would
! 245: seem that it is not true that because the DECL_CHAIN slot is used in
! 246: this way, we cannot call pushdecl to put the method in the global scope
! 247: (cause that would overwrite the TREE_CHAIN slot), because they use
! 248: different _CHAINs.
! 249:
! 250: friends are kept in TREE_LISTs, so that there's no need to use their
! 251: TREE_CHAIN slot for anything.
1.1 root 252:
253: Has values of:
254:
1.1.1.2 ! root 255: TREE_VECs
! 256:
! 257:
! 258: @item CLASSTYPE_VFIELD
! 259: Seems to be in the process of being renamed TYPE_VFIELD. Use on types
! 260: to get the main virtual function table pointer. To get the virtual
! 261: function table use BINFO_VTABLE (TYPE_BINFO ()).
! 262:
! 263: Has values of:
! 264:
! 265: FIELD_DECLs that are virtual function table pointers
1.1 root 266:
267: What things can this be used on:
268:
1.1.1.2 ! root 269: RECORD_TYPEs
! 270:
1.1 root 271:
1.1.1.2 ! root 272: @item DECL_CLASS_CONTEXT
! 273: Identifys the context that the _DECL was found in. For virtual function
! 274: tables, it points to the type associated with the virtual function
! 275: table. See also DECL_CONTEXT, DECL_FIELD_CONTEXT and DECL_FCONTEXT.
! 276:
! 277: The difference between this and DECL_CONTEXT, is that for virtuals
! 278: functions like:
! 279:
! 280: struct A
! 281: {
! 282: virtual int f ();
! 283: };
! 284:
! 285: struct B : A
! 286: {
! 287: int f ();
! 288: };
! 289:
! 290: DECL_CONTEXT (A::f) == A
! 291: DECL_CLASS_CONTEXT (A::f) == A
! 292:
! 293: DECL_CONTEXT (B::f) == A
! 294: DECL_CLASS_CONTEXT (B::f) == B
1.1 root 295:
296: Has values of:
297:
1.1.1.2 ! root 298: RECORD_TYPEs, or UNION_TYPEs
1.1 root 299:
300: What things can this be used on:
301:
1.1.1.2 ! root 302: TYPE_DECLs, _DECLs
1.1 root 303:
1.1.1.2 ! root 304:
! 305: @item DECL_CONTEXT
! 306: Identifys the context that the _DECL was found in. Can be used on
! 307: virtual function tables to find the type associated with the virtual
! 308: function table, but since they are FIELD_DECLs, DECL_FIELD_CONTEXT is a
! 309: better access method. Internally the same as DECL_FIELD_CONTEXT, so
! 310: don't us both. See also DECL_FIELD_CONTEXT, DECL_FCONTEXT and
! 311: DECL_CLASS_CONTEXT.
1.1 root 312:
313: Has values of:
314:
1.1.1.2 ! root 315: RECORD_TYPEs
1.1 root 316:
317:
1.1.1.2 ! root 318: What things can this be used on:
1.1 root 319:
1.1.1.2 ! root 320: VAR_DECLs that are virtual function tables
! 321: _DECLs
1.1 root 322:
323:
1.1.1.2 ! root 324: @item DECL_FIELD_CONTEXT
! 325: Identifys the context that the FIELD_DECL was found in. Internally the
! 326: same as DECL_CONTEXT, so don't us both. See also DECL_CONTEXT,
! 327: DECL_FCONTEXT and DECL_CLASS_CONTEXT.
1.1 root 328:
1.1.1.2 ! root 329: Has values of:
! 330:
! 331: RECORD_TYPEs
! 332:
! 333: What things can this be used on:
! 334:
! 335: FIELD_DECLs that are virtual function pointers
! 336: FIELD_DECLs
1.1 root 337:
1.1.1.2 ! root 338:
! 339: @item DECL_NESTED_TYPENAME
! 340: Holds the fully qualified type name. Example, Base::Derived.
1.1 root 341:
342: Has values of:
343:
1.1.1.2 ! root 344: IDENTIFIER_NODEs
1.1 root 345:
1.1.1.2 ! root 346: What things can this be used on:
1.1 root 347:
1.1.1.2 ! root 348: TYPE_DECLs
1.1 root 349:
350:
1.1.1.2 ! root 351: @item DECL_NAME
! 352:
! 353: Has values of:
! 354:
! 355: 0 for things that don't have names
! 356: IDENTIFIER_NODEs for TYPE_DECLs
1.1 root 357:
358:
359: @item DECL_IGNORED_P
360: A bit that can be set to inform the debug information output routines in
361: the backend that a certain _DECL node should be totally ignored.
362:
363: Used in cases where it is known that the debugging information will be
364: output in another file, or where a sub-type is known not to be needed
365: because the enclosing type is not needed.
366:
367: A compiler constructed virtual destructor in derived classes that do not
368: define an exlicit destructor that was defined exlicit in a base class
369: has this bit set as well. Also used on __FUNCTION__ and
370: __PRETTY_FUNCTION__ to mark they are ``compiler generated.'' c-decl and
371: c-lex.c both want DECL_IGNORED_P set for ``internally generated vars,''
372: and ``user-invisible variable.''
373:
374: Functions built by the C++ front-end such as default destructors,
375: virtual desctructors and default constructors want to be marked that
376: they are compiler generated, but unsure why.
377:
378: Currently, it is used in an absolute way in the C++ front-end, as an
379: optimization, to tell the debug information output routines to not
380: generate debugging information that will be output by another separately
381: compiled file.
382:
383:
1.1.1.2 ! root 384: @item DECL_VIRTUAL_P
! 385: A flag used on FIELD_DECLs and VAR_DECLs. (Documentation in tree.h is
! 386: wrong.) Used in VAR_DECLs to indicate that the variable is a vtable.
! 387: It is also used in FIELD_DECLs for vtable pointers.
1.1 root 388:
1.1.1.2 ! root 389: What things can this be used on:
! 390:
! 391: FIELD_DECLs and VAR_DECLs
1.1 root 392:
1.1.1.2 ! root 393:
! 394: @item DECL_VPARENT
! 395: Used to point to the parent type of the vtable if there is one, else it
! 396: is just the type associated with the vtable. Because of the sharing of
! 397: virtual function tables that goes on, this slot is not very useful, and
! 398: is in fact, not used in the compiler at all. It can be removed.
! 399:
! 400: What things can this be used on:
! 401:
! 402: VAR_DECLs that are virtual function tables
1.1 root 403:
404: Has values of:
405:
1.1.1.2 ! root 406: RECORD_TYPEs maybe UNION_TYPEs
1.1 root 407:
408:
1.1.1.2 ! root 409: @item DECL_FCONTEXT
! 410: Used to find the first baseclass in which this FIELD_DECL is defined.
! 411: See also DECL_CONTEXT, DECL_FIELD_CONTEXT and DECL_CLASS_CONTEXT.
1.1 root 412:
1.1.1.2 ! root 413: How it is used:
! 414:
! 415: Used when writing out debugging information about vfield and
! 416: vbase decls.
1.1 root 417:
418: What things can this be used on:
419:
1.1.1.2 ! root 420: FIELD_DECLs that are virtual function pointers
! 421: FIELD_DECLs
! 422:
! 423:
! 424: @item DECL_REFERENCE_SLOT
! 425: Used to hold the initialize for the reference.
! 426:
! 427: What things can this be used on:
! 428:
! 429: PARM_DECLs and VAR_DECLs that have a reference type
! 430:
1.1 root 431:
432: @item DECL_VINDEX
433: Used for FUNCTION_DECLs in two different ways. Before the structure
434: containing the FUNCTION_DECL is laid out, DECL_VINDEX may point to a
435: FUNCTION_DECL in a base class which is the FUNCTION_DECL which this
436: FUNCTION_DECL will replace as a virtual function. When the class is
437: laid out, this pointer is changed to an INTEGER_CST node which is
1.1.1.2 ! root 438: suitable to find an index into the virtual function table. See
! 439: get_vtable_entry as to how one can find the right index into the virtual
! 440: function table. The first index 0, of a virtual function table it not
! 441: used in the normal way, so the first real index is 1.
1.1 root 442:
443: DECL_VINDEX may be a TREE_LIST, that would seem to be a list of
444: overridden FUNCTION_DECLs. add_virtual_function has code to deal with
445: this when it uses the variable base_fndecl_list, but it would seem that
446: somehow, it is possible for the TREE_LIST to pursist until method_call,
447: and it should not.
448:
1.1.1.2 ! root 449:
! 450: What things can this be used on:
! 451:
! 452: FUNCTION_DECLs
! 453:
! 454:
! 455: @findex DECL_SOURCE_FILE
! 456: @item DECL_SOURCE_FILE
! 457: Identifies what source file a particular declaration was found in.
1.1 root 458:
459: Has values of:
460:
1.1.1.2 ! root 461: "<built-in>" on TYPE_DECLs to mean the typedef is built in
1.1 root 462:
463:
1.1.1.2 ! root 464: @item DECL_SOURCE_LINE
! 465: Identifies what source line number in the source file the declaration
! 466: was found at.
1.1 root 467:
1.1.1.2 ! root 468: Has values of:
! 469:
! 470: 0 for an undefined label
! 471:
! 472: 0 for TYPE_DECLs that are internally generated
! 473:
! 474: 0 for FUNCTION_DECLs for functions generated by the compiler
! 475: (not yet, but should be)
! 476:
! 477: 0 for ``magic'' arguments to functions, that the user has no
! 478: control over
! 479:
! 480:
! 481: @item TREE_USED
1.1 root 482:
483: Has values of:
484:
1.1.1.2 ! root 485: 0 for unused labels
1.1 root 486:
487:
1.1.1.2 ! root 488: @item TREE_ADDRESSABLE
! 489: A flag that is set for any type that has a constructor.
1.1 root 490:
491:
1.1.1.2 ! root 492: @item TREE_COMPLEXITY
! 493: They seem a kludge way to track recursion, poping, and pushing. They only
! 494: appear in cp-decl.c and cp-decl2.c, so the are a good candidate for
! 495: proper fixing, and removal.
! 496:
1.1 root 497:
498: @item TREE_PRIVATE
499: Set for FIELD_DECLs by finish_struct. But not uniformly set.
500:
501: The following routines do something with PRIVATE visibility:
502: build_method_call, alter_visibility, finish_struct_methods,
503: finish_struct, convert_to_aggr, CWriteLanguageDecl, CWriteLanguageType,
504: CWriteUseObject, compute_visibility, lookup_field, dfs_pushdecl,
505: GNU_xref_member, dbxout_type_fields, dbxout_type_method_1
506:
1.1.1.2 ! root 507:
1.1 root 508: @item TREE_PROTECTED
509: The following routines do something with PROTECTED visibility:
510: build_method_call, alter_visibility, finish_struct, convert_to_aggr,
511: CWriteLanguageDecl, CWriteLanguageType, CWriteUseObject,
512: compute_visibility, lookup_field, GNU_xref_member, dbxout_type_fields,
513: dbxout_type_method_1
1.1.1.2 ! root 514:
! 515:
! 516: @item TYPE_BINFO
! 517: Used to get the binfo for the type.
! 518:
! 519: Has values of:
! 520:
! 521: TREE_VECs that are binfos
! 522:
! 523: What things can this be used on:
! 524:
! 525: RECORD_TYPEs
! 526:
! 527:
! 528: @item TYPE_BINFO_BASETYPES
! 529: See also BINFO_BASETYPES.
! 530:
! 531: @item TYPE_BINFO_VIRTUALS
! 532: A unique list of functions for the virtual function table. See also
! 533: BINFO_VIRTUALS.
! 534:
! 535: What things can this be used on:
! 536:
! 537: RECORD_TYPEs
! 538:
! 539:
! 540: @item TYPE_BINFO_VTABLE
! 541: Points to the virtual function table associated with the given type.
! 542: See also BINFO_VTABLE.
! 543:
! 544: What things can this be used on:
! 545:
! 546: RECORD_TYPEs
! 547:
! 548: Has values of:
! 549:
! 550: VAR_DECLs that are virtual function tables
! 551:
! 552:
! 553: @item TYPE_NAME
! 554: Names the type.
! 555:
! 556: Has values of:
! 557:
! 558: 0 for things that don't have names.
! 559: should be IDENTIFIER_NODE for RECORD_TYPEs UNION_TYPEs and ENUM_TYPEs.
! 560: TYPE_DECL for RECORD_TYPEs, UNION_TYPEs and ENUM_TYPEs, but shouldn't
! 561: be.
! 562: TYPE_DECL for typedefs, unsure why.
! 563:
! 564: What things can one use this on:
! 565:
! 566: TYPE_DECLs
! 567: RECORD_TYPEs
! 568: UNION_TYPEs
! 569: ENUM_TYPEs
! 570:
! 571: How it is used:
! 572:
! 573: Used by dwarfout.c to fetch the name of structs, unoins and enums
! 574: to create AT_name fields.
! 575:
! 576: History:
! 577:
! 578: It currently points to the TYPE_DECL for RECORD_TYPEs,
! 579: UNION_TYPEs and ENUM_TYPEs, but it should be history soon.
! 580:
! 581:
! 582: @item TYPE_METHODS
! 583: Synonym for CLASSTYPE_METHOD_VEC. Chained together with TREE_CHAIN.
! 584: dbxout.c uses this to get at the methods of a class.
! 585:
! 586:
! 587: @item TYPE_DECL
! 588: Used to represent typedefs, and used to represent bindings layers.
! 589:
! 590: Components:
! 591:
! 592: DECL_NAME is the name of the typedef. For example, foo would
! 593: be found in the DECL_NAME slot when @code{typedef int foo;} is
! 594: seen.
! 595:
! 596: DECL_SOURCE_LINE identifies what source line number in the
! 597: source file the declaration was found at. A value of 0
! 598: indicates that this TYPE_DECL is just an internal binding layer
! 599: marker, and does not correspond to a user suppiled typedef.
! 600:
! 601: DECL_SOURCE_FILE @xref{DECL_SOURCE_FILE}.
! 602:
! 603:
! 604: @item TYPE_FIELDS
! 605: TYPE_FIELDS is a linked list (via TREE_CHAIN) of member types of a
! 606: class. The list can contain TYPE_DECLs, but there can also be other
! 607: things in the list apparently. See also CLASSTYPE_TAGS.
! 608:
! 609:
! 610: @item TYPE_VIRTUAL_P
! 611: A flag used on a FIELD_DECL or a VAR_DECL, indicates it is a virtual
! 612: function table or a pointer to one. When used on a FUNCTION_DECL,
! 613: indicates that it is a virtual function. When used on an
! 614: IDENTIFIER_NODE, indicates that a function with this same name exists
! 615: and has been declared virtual.
! 616:
! 617: When used on _TYPEs, it indicates that the type has virtual functions,
! 618: or is derived from one that does.
! 619:
! 620: Not sure if the above about virtual function tables is still true. See
! 621: also DECL_VIRTUAL_P.
! 622:
! 623: What things can this be used on:
! 624:
! 625: FIELD_DECLs, VAR_DECLs, FUNCTION_DECLs, IDENTIFIER_NODEs
! 626:
! 627:
! 628: @item VF_BASETYPE_VALUE
! 629: Get the associated type from the binfo that caused the given vfield to
! 630: exist. This is the least derived class (the most parent class) that
! 631: needed a virtual function table. It is probably the case that all uses
! 632: of this field are misguided, but they need to be examined on a
! 633: case-by-case basis. See history for more information on why the
! 634: previous statement was made.
! 635:
! 636: What things can this be used on:
! 637:
! 638: TREE_LISTs that are vfields
! 639:
! 640: History:
! 641:
! 642: This field was used to determine if a virtual function table's
! 643: slot should be filled in with a certain virtual function, by
! 644: checking to see if the type returned by VF_BASETYPE_VALUE was a
! 645: parent of the context in which the old virtual function existed.
! 646: This incorrectly assumes that a given type _could_ not appear as
! 647: a parent twice in a given inheritance lattice. For single
! 648: inheritance, this would in fact work, because a type could not
! 649: possibly appear more than once in an inheritance lattice, but
! 650: with multiple inheritance, a type can appear more than once.
! 651:
! 652:
! 653: @item VF_BINFO_VALUE
! 654: Identifies the binfo that caused this vfield to exist. Can use
! 655: TREE_VIA_VIRTUAL on result to find out if it is a virtual base class.
! 656: Related to the binfo found by get_binfo (VF_BASETYPE_VALUE (vfield), t,
! 657: 0) where t is the type that has the given vfield. get_binfo
! 658: (VF_BASETYPE_VALUE (vfield), t, 0) will return the binfo for the
! 659: the given vfield.
! 660:
! 661: May or may not be set at modify_vtable_entries time. Set at
! 662: finish_base_struct time.
! 663:
! 664: What things can this be used on:
! 665:
! 666: TREE_LISTs that are vfields
! 667:
! 668:
! 669:
! 670: @node Typical Behavior
! 671: @section Typical Behavior
! 672:
! 673: @index parse errors
! 674:
! 675: Whenever seemingly normal code fails with errors like
! 676: @tt{syntax error at `\{'}, it's highly likely that grokdeclarator is
! 677: returning a NULL_TREE for whatever reason.
! 678:
! 679: @index pure virtual functions
! 680:
! 681: The compiler (in grok_function_init) explicitly makes the RTL for a pure
! 682: virtual function be a call to abort(2). The ARM and the ANSI draft are
! 683: unclear about what the "right" behavior should be. The ARM in $10.3
! 684: notes that a likely result of calling a pure virtual fn is a core dump.
! 685: cfront doesn't compile anything out, and yields an undefined symbol for
! 686: the base's pure virtual function. Until the standard says different,
! 687: g++ is doing the right thing. (brendan)
! 688:
! 689: The above is WRONG. ARM and ANSI working paper are very clear about it.
! 690: cfront yets it right. g++ gets (or used to get it) wrong. (mrs)
! 691:
! 692: @node Coding Conventions
! 693: @section Coding Conventions
! 694:
! 695: It should never be that case that trees are modified in-place by the
! 696: back-end, UNLESS it is guaranteed that the semantics are the same no
! 697: matter how shared the tree structure is. fold-const.c still has some
! 698: cases where this is not true, but rms hypothesizes that this will never
! 699: be a problem.
! 700:
! 701: The term `child' is used when dealing with elements of binfos, even
! 702: though more derived classes are usually called children and base classes
! 703: are called parents. So in the code, the variable `child' really means
! 704: parent or the base class. Also, other terms related to child like,
! 705: down, under and beneath refer to going from the most derived class to
! 706: lesser derived classes. For example old comments would say ``Here we
! 707: travel down from Child to Parent'' or ``Parent is under Child'' given
! 708: the code below. The types of comments should be re-worded to not use
! 709: such ambiguous wording.
! 710:
! 711: class Parent {
! 712: };
! 713:
! 714: class Child : Parent {
! 715: };
! 716:
! 717: is the normal way of calling things.
! 718:
! 719: This confusing terminology needs to be renamed en-mass at some point in
! 720: time.
! 721:
! 722: Ok, the above has been done. Here is a conversion table:
! 723:
! 724: old name new name
! 725: child base_binfo
! 726: child_child base_base_binfo
! 727: child_binfos base_binfos
! 728: .*_child .*_base_binfo
! 729:
! 730:
! 731: I asked everyone about the
! 732:
! 733: #if 0 /* not yet, should get fixed properly later */
! 734:
! 735: code everywhere and raeburn said:
! 736:
! 737: From [email protected] Wed Oct 21 20:04:58 1992
! 738: Date: Wed, 21 Oct 92 23:04:53 EDT
! 739: From: [email protected] (Ken Raeburn)
! 740: To: [email protected]
! 741: In-Reply-To: <[email protected]> (mrs)
! 742: Subject: g++
! 743:
! 744: Sounds like something I might have put in there when working on template
! 745: problems (probably trying to deal with producing an assembly name for each
! 746: defined type), but I'm not sure. Go ahead and flip 'em.
! 747:
! 748: @bye
! 749:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.