tree.def: Improve RAW_DATA_CST documentation

Message ID Z9E3AgX7CUjOfSbu@tucnak
State New
Headers
Series tree.def: Improve RAW_DATA_CST documentation |

Checks

Context Check Description
linaro-tcwg-bot/tcwg_gcc_build--master-aarch64 fail Patch failed to apply
linaro-tcwg-bot/tcwg_gcc_build--master-arm fail Patch failed to apply
linaro-tcwg-bot/tcwg_simplebootstrap_build--master-aarch64-bootstrap fail Patch failed to apply
linaro-tcwg-bot/tcwg_simplebootstrap_build--master-arm-bootstrap fail Patch failed to apply

Commit Message

Jakub Jelinek March 12, 2025, 7:25 a.m. UTC
  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?

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.


	Jakub
  

Comments

Richard Biener March 12, 2025, 8:13 a.m. UTC | #1
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  <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.
> 
> --- 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
> 
>
  

Patch

--- 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