On Wed, 12 Mar 2025, Jakub Jelinek wrote: > Hi! > > 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. > > Ok for trunk?
OK. Richard. > 2025-03-12 Jakub Jelinek <ja...@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. > > --- gcc/tree.def.jj 2025-01-15 08:43:39.818915636 +0100 > +++ gcc/tree.def 2025-03-12 08:11:24.230196310 +0100 > @@ -313,7 +313,9 @@ DEFTREECODE (STRING_CST, "string_cst", t > 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 > 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 > > Jakub > > -- Richard Biener <rguent...@suse.de> SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
