tree.def: Improve RAW_DATA_CST documentation
In PR117262 David was asking for better documentation of RAW_DATA_CST and in the review of the PR119076 patch Jason was asking for that as well. Here is an attempt to do so. 2025-03-12 Jakub Jelinek <jakub@redhat.com> * tree.def (RAW_DATA_CST): Document meaning of NULL RAW_DATA_OWNER. (CONSTRUCTOR): Document meaning of RAW_DATA_CST used as element value.
This commit is contained in:
parent
5712e33378
commit
0787a65d95
1 changed files with 11 additions and 1 deletions
12
gcc/tree.def
12
gcc/tree.def
|
@ -313,7 +313,9 @@ DEFTREECODE (STRING_CST, "string_cst", tcc_constant, 0)
|
|||
of the raw data, plus RAW_DATA_OWNER for owner of the
|
||||
data. That can be either a STRING_CST, used e.g. when writing
|
||||
PCH header, or another RAW_DATA_CST representing data owned by
|
||||
libcpp and representing the original range (if possible).
|
||||
libcpp and representing the original range (if possible)
|
||||
or NULL_TREE if it is the RAW_DATA_OWNER of other RAW_DATA_CST
|
||||
nodes (and represents data owned by libcpp).
|
||||
TREE_TYPE is the type of each of the RAW_DATA_LENGTH elements. */
|
||||
DEFTREECODE (RAW_DATA_CST, "raw_data_cst", tcc_constant, 0)
|
||||
|
||||
|
@ -505,6 +507,14 @@ DEFTREECODE (OBJ_TYPE_REF, "obj_type_ref", tcc_expression, 3)
|
|||
one for each index in the range. (If the corresponding field VALUE
|
||||
has side-effects, they are evaluated once for each element. Wrap the
|
||||
value in a SAVE_EXPR if you want to evaluate side effects only once.)
|
||||
If the index is INTEGER_CST or NULL_TREE and value RAW_DATA_CST, it is
|
||||
a short-hand for RAW_DATA_LENGTH consecutive nodes, first at the given
|
||||
index or current location, each node being
|
||||
build_int_cst (TREE_TYPE (value), TYPE_UNSIGNED (TREE_TYPE (value))
|
||||
? (HOST_WIDE_INT) RAW_DATA_UCHAR_ELT (value, n)
|
||||
: (HOST_WIDE_INT) RAW_DATA_SCHAR_ELT (value, n)) at index
|
||||
tree_to_uhwi (index) + n (or current location + n) for n from 0 to
|
||||
RAW_DATA_LENGTH (value) - 1.
|
||||
|
||||
Components that aren't present are cleared as per the C semantics,
|
||||
unless the CONSTRUCTOR_NO_CLEARING flag is set, in which case their
|
||||
|
|
Loading…
Add table
Reference in a new issue