On 12-08-14 01:39 , Laurynas Biveinis wrote:
(walk_type): Set D->IN_PTR_FILED when walking a TYPE_POINTER.
"FIELD"
Done.
+fields is completely handled by user-provided routines. Section
+@ref{User GC} for details on what functions need to be provided.
"See Section ... " ?
Done.
+code is generated. For these types, the user is required to provide
+three functions: one to act as a marker for garbage collection, and
+two functions to act as marker and pointer walking for pre-compiled
+headers.
s/walking/walker ?
Done.
+In general, each marker @code{M} should call @code{M} for every
+pointer field in the structure. Fields that are not allocated in GC
+or are not pointers can be ignored.
"must be ignored"
Done.
+create_user_defined_type (const char *type_name, struct fileloc *pos)
...
+ template by preteding that each type is a field of TY. This is needed to
pretending
Done.
@@ -548,20 +603,30 @@ resolve_typedef (const char *s, struct fileloc *pos)
for (p = typedefs; p != NULL; p = p->next)
if (strcmp (p->name, s) == 0)
return p->type;
- error_at_line (pos, "unidentified type `%s'", s);
- return &scalar_nonchar; /* treat as "int" */
+
+ /* If we did not find a typedef registered, assume this is a name
+ for a user-defined type which will need to provide its own
+ marking functions.
+
+ FIXME cxx-conversion. Emit an error once explicit annotations
+ for marking user types are implemented. */
+ return create_user_defined_type (s, pos);
Are "explicit annotations for marking user types" referring to GTY((user))?
Actually, the comment is wrong. When we don't recognize the type, we
simply consider this type as implicitly user-defined.
+static const char *
+filter_type_name (const char *type_name)
+{
Maybe this function should return const-less char *? The casts to cast
the const away for freeing it look a bit awkward.
Done.
+
+/* User-callable entry point for marking string X. */
"points"
Done.
+
+/* User-callable entry point for marking string X. */
"points"
Done.
--- a/gcc/stringpool.c
+++ b/gcc/stringpool.c
@@ -49,7 +49,7 @@ static const char digit_vector[] = {
struct ht *ident_hash;
-static hashnode alloc_node (hash_table *);
+static hashnode alloc_node (cpp_hash_table *);
static int mark_ident (struct cpp_reader *, hashnode, const void *);
static void *
@@ -70,7 +70,7 @@ init_stringpool (void)
/* Allocate a hash node. */
static hashnode
-alloc_node (hash_table *table ATTRIBUTE_UNUSED)
+alloc_node (cpp_hash_table *table ATTRIBUTE_UNUSED)
{
return GCC_IDENT_TO_HT_IDENT (make_node (IDENTIFIER_NODE));
}
These changes are not in the ChangeLog, are they intentional?
Sorry. They belong to the hash table patch. Both patches touched the
same file and I missed splitting these hunks.
diff --git a/gcc/tree-cfg.c b/gcc/tree-cfg.c
+/* Garbage collection support for edge_def. */
+
+extern void gt_ggc_mx (tree&);
+extern void gt_ggc_mx (gimple&);
+extern void gt_ggc_mx (rtx&);
+extern void gt_ggc_mx (basic_block&);
+/* PCH support for edge_def. */
+
+extern void gt_pch_nx (tree&);
+extern void gt_pch_nx (gimple&);
+extern void gt_pch_nx (rtx&);
+extern void gt_pch_nx (basic_block&);
I wonder if these externs can be avoided by including gtype-desc.h. I
realize that gtype-desc.h declares a lot of stuff, but if tree-cfg.c
already declares GC roots, then it already should be pulling that
header in in through gt-tree-cfg.h.
Not really. These are never really defined anywhere. They are emitted
in gtype-desc.c, but we never emit prototypes for them. Going down that
road ends up in turning gengtype upside-down.
Diego.
