update a few places for the change from gimple_statement_base to gimple
gcc/ChangeLog: 2015-09-28 Trevor Saunders <tbsaunde+gcc@tbsaunde.org> * doc/gimple.texi: Update references to gimple_statement_base. * gdbhooks.py: Likewise. * gimple.h: Likewise. From-SVN: r228192
This commit is contained in:
Trevor Saunders
Trevor Saunders
parent
8b1785f0fa
commit
7b95476612
|
|
@ -1,3 +1,9 @@
|
|||
2015-09-28 Trevor Saunders <tbsaunde+gcc@tbsaunde.org>
|
||||
|
||||
* doc/gimple.texi: Update references to gimple_statement_base.
|
||||
* gdbhooks.py: Likewise.
|
||||
* gimple.h: Likewise.
|
||||
|
||||
2015-09-28 Daniel Cederman <cederman@gaisler.com>
|
||||
|
||||
* config/sparc/driver-sparc.c: map LEON to leon3
|
||||
|
|
|
|||
|
|
@ -92,8 +92,8 @@ groups: a header describing the instruction and its locations,
|
|||
and a variable length body with all the operands. Tuples are
|
||||
organized into a hierarchy with 3 main classes of tuples.
|
||||
|
||||
@subsection @code{gimple_statement_base} (gsbase)
|
||||
@cindex gimple_statement_base
|
||||
@subsection @code{gimple} (gsbase)
|
||||
@cindex gimple
|
||||
|
||||
This is the root of the hierarchy, it holds basic information
|
||||
needed by most GIMPLE statements. There are some fields that
|
||||
|
|
@ -223,7 +223,7 @@ is then inherited from the other two tuples.
|
|||
|
||||
@itemize @bullet
|
||||
@item @code{gsbase}
|
||||
Inherited from @code{struct gimple_statement_base}.
|
||||
Inherited from @code{struct gimple}.
|
||||
|
||||
@item @code{def_ops}
|
||||
Array of pointers into the operand array indicating all the slots that
|
||||
|
|
@ -300,7 +300,7 @@ kinds, along with their relationships to @code{GSS_} values (layouts) and
|
|||
@code{GIMPLE_} values (codes):
|
||||
|
||||
@smallexample
|
||||
gimple_statement_base
|
||||
gimple
|
||||
| layout: GSS_BASE
|
||||
| used for 4 codes: GIMPLE_ERROR_MARK
|
||||
| GIMPLE_NOP
|
||||
|
|
@ -2654,7 +2654,7 @@ any new basic blocks which are necessary.
|
|||
|
||||
The first step in adding a new GIMPLE statement code, is
|
||||
modifying the file @code{gimple.def}, which contains all the GIMPLE
|
||||
codes. Then you must add a corresponding gimple_statement_base subclass
|
||||
codes. Then you must add a corresponding gimple subclass
|
||||
located in @code{gimple.h}. This in turn, will require you to add a
|
||||
corresponding @code{GTY} tag in @code{gsstruct.def}, and code to handle
|
||||
this tag in @code{gss_for_code} which is located in @code{gimple.c}.
|
||||
|
|
@ -2667,7 +2667,7 @@ in @code{gimple.c}.
|
|||
You will probably want to create a function to build the new
|
||||
gimple statement in @code{gimple.c}. The function should be called
|
||||
@code{gimple_build_@var{new-tuple-name}}, and should return the new tuple
|
||||
as a pointer to the appropriate gimple_statement_base subclass.
|
||||
as a pointer to the appropriate gimple subclass.
|
||||
|
||||
If your new statement requires accessors for any members or
|
||||
operands it may have, put simple inline accessors in
|
||||
|
|
|
|||
|
|
@ -484,7 +484,7 @@ def build_pretty_printer():
|
|||
'cgraph_node', CGraphNodePrinter)
|
||||
pp.add_printer_for_types(['dw_die_ref'],
|
||||
'dw_die_ref', DWDieRefPrinter)
|
||||
pp.add_printer_for_types(['gimple', 'gimple_statement_base *',
|
||||
pp.add_printer_for_types(['gimple', 'gimple *',
|
||||
|
||||
# Keep this in the same order as gimple.def:
|
||||
'gimple_cond', 'const_gimple_cond',
|
||||
|
|
|
|||
10
gcc/gimple.h
10
gcc/gimple.h
|
|
@ -123,7 +123,7 @@ enum gimple_rhs_class
|
|||
};
|
||||
|
||||
/* Specific flags for individual GIMPLE statements. These flags are
|
||||
always stored in gimple_statement_base.subcode and they may only be
|
||||
always stored in gimple.subcode and they may only be
|
||||
defined for statement codes that do not use subcodes.
|
||||
|
||||
Values for the masks can overlap as long as the overlapping values
|
||||
|
|
@ -380,7 +380,7 @@ struct GTY((tag("GSS_BIND")))
|
|||
tree vars;
|
||||
|
||||
/* [ WORD 8 ]
|
||||
This is different than the BLOCK field in gimple_statement_base,
|
||||
This is different than the BLOCK field in gimple,
|
||||
which is analogous to TREE_BLOCK (i.e., the lexical block holding
|
||||
this statement). This field is the equivalent of BIND_EXPR_BLOCK
|
||||
in tree land (i.e., the lexical scope defined by this bind). See
|
||||
|
|
@ -744,7 +744,7 @@ struct GTY((tag("GSS_OMP_SINGLE_LAYOUT")))
|
|||
|
||||
|
||||
/* GIMPLE_OMP_ATOMIC_LOAD.
|
||||
Note: This is based on gimple_statement_base, not g_s_omp, because g_s_omp
|
||||
Note: This is based on gimple, not g_s_omp, because g_s_omp
|
||||
contains a sequence, which we don't need here. */
|
||||
|
||||
struct GTY((tag("GSS_OMP_ATOMIC_LOAD")))
|
||||
|
|
@ -1813,7 +1813,7 @@ gimple_set_no_warning (gimple *stmt, bool no_warning)
|
|||
|
||||
You can learn more about the visited property of the gimple
|
||||
statement by reading the comments of the 'visited' data member of
|
||||
struct gimple statement_base.
|
||||
struct gimple.
|
||||
*/
|
||||
|
||||
static inline void
|
||||
|
|
@ -1832,7 +1832,7 @@ gimple_set_visited (gimple *stmt, bool visited_p)
|
|||
|
||||
You can learn more about the visited property of the gimple
|
||||
statement by reading the comments of the 'visited' data member of
|
||||
struct gimple statement_base. */
|
||||
struct gimple. */
|
||||
|
||||
static inline bool
|
||||
gimple_visited_p (gimple *stmt)
|
||||
|
|
|
|||
Loading…
Reference in New Issue