Hi!

On 2022-10-18T18:14:54-0400, Lewis Hyatt via Gcc-patches <gcc-patches@gcc.gnu.org> wrote:
> [...] add a new
> GTY option "string_length" so that gt_pch_note_object can be informed the
> actual length it ought to use, [...]

> --- a/gcc/doc/gty.texi
> +++ b/gcc/doc/gty.texi
> @@ -196,7 +196,26 @@ static GTY((length("reg_known_value_size"))) rtx *reg_known_value;
>  Note that the @code{length} option is only meant for use with arrays of
>  non-atomic objects, that is, objects that contain pointers pointing to
>  other GTY-managed objects.  For other GC-allocated arrays and strings
> -you should use @code{atomic}.
> +you should use @code{atomic} or @code{string_length}.
> +
> +@findex string_length
> +@item string_length ("@var{expression}")
> +
> +In order to simplify production of PCH, a structure member that is a plain
> +array of bytes (an optionally @code{const} and/or @code{unsigned} @code{char
> +*}) is treated specially by the infrastructure. Even if such an array has not
> +been allocated in GC-controlled memory, it will still be written properly into
> +a PCH.  The machinery responsible for this needs to know the length of the
> +data; by default, the length is determined by calling @code{strlen} on the
> +pointer.  The @code{string_length} option specifies an alternate way to
> +determine the length, such as by inspecting another struct member:
> +
> +@smallexample
> +struct GTY(()) non_terminated_string @{
> +  size_t sz;
> +  const char * GTY((string_length ("%h.sz"))) data;
> +@};
> +@end smallexample

In preparation for another thing I'm working on, OK to push the attached
"GTY: Explicitly reject 'string_length' option for (fields in) global variables"
(with <https://inbox.sourceware.org/[TODO]> pointing to this message)?


Grüße
 Thomas


-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955