gxxint.texi

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

\input texinfo  @c -*-texinfo-*-
@c %**start of header 
@setfilename g++int.info
@settitle G++ internals
@setchapternewpage odd
@c %**end of header
     
@node Top, Limitations of g++, (dir), (dir)
@chapter Internal Architecture of the Compiler

This is meant to describe the C++ front-end for gcc in detail.
Questions and comments to mrs@@cygnus.com.

@menu
* Limitations of g++::          
* Routines::                    
* Implementation Specifics::    
* Glossary::                    
* Macros::                      
* Typical Behavior::            
* Coding Conventions::          
* Templates::                   
* Access Control::              
* Error Reporting::             
* Parser::                      
* Copying Objects::             
* Exception Handling::          
* Free Store::                  
* Concept Index::               
@end menu

@node Limitations of g++, Routines, Top, Top
@section Limitations of g++

@itemize @bullet
@item
Limitations on input source code: 240 nesting levels with the parser
stacksize (YYSTACKSIZE) set to 500 (the default), and requires around
16.4k swap space per nesting level.  The parser needs about 2.09 *
number of nesting levels worth of stackspace.

@cindex pushdecl_class_level
@item
I suspect there are other uses of pushdecl_class_level that do not call
set_identifier_type_value in tandem with the call to
pushdecl_class_level.  It would seem to be an omission.

@cindex access checking
@item
Access checking is unimplemented for nested types.

@cindex @code{volatile}
@item
@code{volatile} is not implemented in general.

@cindex pointers to members
@item
Pointers to members are only minimally supported, and there are places
where the grammar doesn't even properly accept them yet.

@cindex multiple inheritance
@item
@code{this} will be wrong in virtual members functions defined in a
virtual base class, when they are overridden in a derived class, when
called via a non-left most object.

An example would be:

@example
extern "C" int printf(const char*, ...);
struct A @{ virtual void f() @{ @} @};
struct B : virtual A @{ int b; B() : b(0) @{@} void f() @{ b++; @} @};
struct C : B @{@};
struct D : B @{@};
struct E : C, D @{@};
int main()
@{
  E e;
  C& c = e; D& d = e;
  c.f(); d.f();
  printf ("C::b = %d, D::b = %d\n", e.C::b, e.D::b);
  return 0;
@}
@end example

This will print out 2, 0, instead of 1,1.

@end itemize

@node Routines, Implementation Specifics, Limitations of g++, Top
@section Routines

This section describes some of the routines used in the C++ front-end.

@code{build_vtable} and @code{prepare_fresh_vtable} is used only within
the @file{cp-class.c} file, and only in @code{finish_struct} and
@code{modify_vtable_entries}.

@code{build_vtable}, @code{prepare_fresh_vtable}, and
@code{finish_struct} are the only routines that set @code{DECL_VPARENT}.

@code{finish_struct} can steal the virtual function table from parents,
this prohibits related_vslot from working.  When finish_struct steals,
we know that

@example
get_binfo (DECL_FIELD_CONTEXT (CLASSTYPE_VFIELD (t)), t, 0)
@end example

@noindent
will get the related binfo.

@code{layout_basetypes} does something with the VIRTUALS.

Supposedly (according to Tiemann) most of the breadth first searching
done, like in @code{get_base_distance} and in @code{get_binfo} was not
because of any design decision.  I have since found out the at least one
part of the compiler needs the notion of depth first binfo searching, I
am going to try and convert the whole thing, it should just work.  The
term left-most refers to the depth first left-most node.  It uses
@code{MAIN_VARIANT == type} as the condition to get left-most, because
the things that have @code{BINFO_OFFSET}s of zero are shared and will
have themselves as their own @code{MAIN_VARIANT}s.  The non-shared right
ones, are copies of the left-most one, hence if it is its own
@code{MAIN_VARIANT}, we know it IS a left-most one, if it is not, it is
a non-left-most one.

@code{get_base_distance}'s path and distance matters in its use in:

@itemize @bullet
@item
@code{prepare_fresh_vtable} (the code is probably wrong)
@item
@code{init_vfields} Depends upon distance probably in a safe way,
build_offset_ref might use partial paths to do further lookups,
hack_identifier is probably not properly checking access.

@item
@code{get_first_matching_virtual} probably should check for
@code{get_base_distance} returning -2.

@item
@code{resolve_offset_ref} should be called in a more deterministic
manner.  Right now, it is called in some random contexts, like for
arguments at @code{build_method_call} time, @code{default_conversion}
time, @code{convert_arguments} time, @code{build_unary_op} time,
@code{build_c_cast} time, @code{build_modify_expr} time,
@code{convert_for_assignment} time, and
@code{convert_for_initialization} time.

But, there are still more contexts it needs to be called in, one was the
ever simple:

@example
if (obj.*pmi != 7)
   @dots{}
@end example

Seems that the problems were due to the fact that @code{TREE_TYPE} of
the @code{OFFSET_REF} was not a @code{OFFSET_TYPE}, but rather the type
of the referent (like @code{INTEGER_TYPE}).  This problem was fixed by
changing @code{default_conversion} to check @code{TREE_CODE (x)},
instead of only checking @code{TREE_CODE (TREE_TYPE (x))} to see if it
was @code{OFFSET_TYPE}.

@end itemize

@node Implementation Specifics, Glossary, Routines, Top
@section Implementation Specifics

@itemize @bullet
@item Explicit Initialization

The global list @code{current_member_init_list} contains the list of
mem-initializers specified in a constructor declaration.  For example:

@example
foo::foo() : a(1), b(2) @{@}
@end example

@noindent
will initialize @samp{a} with 1 and @samp{b} with 2.
@code{expand_member_init} places each initialization (a with 1) on the
global list.  Then, when the fndecl is being processed,
@code{emit_base_init} runs down the list, initializing them.  It used to
be the case that g++ first ran down @code{current_member_init_list},
then ran down the list of members initializing the ones that weren't
explicitly initialized.  Things were rewritten to perform the
initializations in order of declaration in the class.  So, for the above
example, @samp{a} and @samp{b} will be initialized in the order that
they were declared:

@example
class foo @{ public: int b; int a; foo (); @};
@end example

@noindent
Thus, @samp{b} will be initialized with 2 first, then @samp{a} will be
initialized with 1, regardless of how they're listed in the mem-initializer.

@item Argument Matching

In early 1993, the argument matching scheme in @sc{gnu} C++ changed
significantly.  The original code was completely replaced with a new
method that will, hopefully, be easier to understand and make fixing
specific cases much easier.

The @samp{-fansi-overloading} option is used to enable the new code; at
some point in the future, it will become the default behavior of the
compiler.

The file @file{cp-call.c} contains all of the new work, in the functions
@code{rank_for_overload}, @code{compute_harshness},
@code{compute_conversion_costs}, and @code{ideal_candidate}.

Instead of using obscure numerical values, the quality of an argument
match is now represented by clear, individual codes.  The new data
structure @code{struct harshness} (it used to be an @code{unsigned}
number) contains:

@enumerate a
@item the @samp{code} field, to signify what was involved in matching two
arguments;
@item the @samp{distance} field, used in situations where inheritance
decides which function should be called (one is ``closer'' than
another);
@item and the @samp{int_penalty} field, used by some codes as a tie-breaker.
@end enumerate

The @samp{code} field is a number with a given bit set for each type of
code, OR'd together.  The new codes are:

@itemize @bullet
@item @code{EVIL_CODE}
The argument was not a permissible match.

@item @code{CONST_CODE}
Currently, this is only used by @code{compute_conversion_costs}, to
distinguish when a non-@code{const} member function is called from a
@code{const} member function.

@item @code{ELLIPSIS_CODE}
A match against an ellipsis @samp{...} is considered worse than all others.

@item @code{USER_CODE}
Used for a match involving a user-defined conversion.

@item @code{STD_CODE}
A match involving a standard conversion.

@item @code{PROMO_CODE}
A match involving an integral promotion.  For these, the
@code{int_penalty} field is used to handle the ARM's rule (XXX cite)
that a smaller @code{unsigned} type should promote to a @code{int}, not
to an @code{unsigned int}.

@item @code{QUAL_CODE}
Used to mark use of qualifiers like @code{const} and @code{volatile}.

@item @code{TRIVIAL_CODE}
Used for trivial conversions.  The @samp{int_penalty} field is used by
@code{convert_harshness} to communicate further penalty information back
to @code{build_overload_call_real} when deciding which function should
be call.
@end itemize

The functions @code{convert_to_aggr} and @code{build_method_call} use
@code{compute_conversion_costs} to rate each argument's suitability for
a given candidate function (that's how we get the list of candidates for
@code{ideal_candidate}).

@end itemize

@node Glossary, Macros, Implementation Specifics, Top
@section Glossary

@table @r
@item binfo
The main data structure in the compiler used to represent the
inheritance relationships between classes.  The data in the binfo can be
accessed by the BINFO_ accessor macros.

@item vtable
@itemx virtual function table

The virtual function table holds information used in virtual function
dispatching.  In the compiler, they are usually referred to as vtables,
or vtbls.  The first index is not used in the normal way, I believe it
is probably used for the virtual destructor.

@item vfield

vfields can be thought of as the base information needed to build
vtables.  For every vtable that exists for a class, there is a vfield.
See also vtable and virtual function table pointer.  When a type is used
as a base class to another type, the virtual function table for the
derived class can be based upon the vtable for the base class, just
extended to include the additional virtual methods declared in the
derived class.  The virtual function table from a virtual base class is
never reused in a derived class.  @code{is_normal} depends upon this.

@item virtual function table pointer

These are @code{FIELD_DECL}s that are pointer types that point to
vtables.  See also vtable and vfield.
@end table

@node Macros, Typical Behavior, Glossary, Top
@section Macros

This section describes some of the macros used on trees.  The list
should be alphabetical.  Eventually all macros should be documented
here.  There are some postscript drawings that can be used to better
understand from of the more complex data structures, contact Mike Stump
(@code{mrs@@cygnus.com}) for information about them.

@table @code
@item BINFO_BASETYPES
A vector of additional binfos for the types inherited by this basetype.
The binfos are fully unshared (except for virtual bases, in which
case the binfo structure is shared).

   If this basetype describes type D as inherited in C,
   and if the basetypes of D are E anf F,
   then this vector contains binfos for inheritance of E and F by C.

Has values of:

	TREE_VECs


@item BINFO_INHERITANCE_CHAIN
Temporarily used to represent specific inheritances.  It usually points
to the binfo associated with the lesser derived type, but it can be
reversed by reverse_path.  For example:

@example
	Z ZbY	least derived
	|
	Y YbX
	|
	X Xb	most derived

TYPE_BINFO (X) == Xb
BINFO_INHERITANCE_CHAIN (Xb) == YbX
BINFO_INHERITANCE_CHAIN (Yb) == ZbY
BINFO_INHERITANCE_CHAIN (Zb) == 0
@end example

Not sure is the above is really true, get_base_distance has is point
towards the most derived type, opposite from above.

Set by build_vbase_path, recursive_bounded_basetype_p,
get_base_distance, lookup_field, lookup_fnfields, and reverse_path.

What things can this be used on:

	TREE_VECs that are binfos


@item BINFO_OFFSET
The offset where this basetype appears in its containing type.
BINFO_OFFSET slot holds the offset (in bytes) from the base of the
complete object to the base of the part of the object that is allocated
on behalf of this `type'.  This is always 0 except when there is
multiple inheritance.

Used on TREE_VEC_ELTs of the binfos BINFO_BASETYPES (...) for example.


@item BINFO_VIRTUALS
A unique list of functions for the virtual function table.  See also
TYPE_BINFO_VIRTUALS.

What things can this be used on:

	TREE_VECs that are binfos


@item BINFO_VTABLE
Used to find the VAR_DECL that is the virtual function table associated
with this binfo.  See also TYPE_BINFO_VTABLE.  To get the virtual
function table pointer, see CLASSTYPE_VFIELD.

What things can this be used on:

	TREE_VECs that are binfos

Has values of:

	VAR_DECLs that are virtual function tables


@item BLOCK_SUPERCONTEXT
In the outermost scope of each function, it points to the FUNCTION_DECL
node.  It aids in better DWARF support of inline functions.