Re: GTY: Repair 'enum gty_token', 'token_names' desynchronization (was: [cxx-conversion] Support garbage-collected C++ templates)
On Wed, Jul 5, 2023 at 12:21 PM Thomas Schwinge wrote:
>
> Hi!
>
> On 2012-08-10T11:06:46-0400, Diego Novillo wrote:
> > * gengtype-lex.l (USER_GTY): Add pattern for "user".
> > * gengtype-parse.c (option): Handle USER_GTY.
> > (opts_have): New.
> > (type): Call it.
> > If the keyword 'user' is used, do not walk the fields
> > of the structure.
> > * gengtype.h (USER_GTY): Add.
>
> These changes got incorporated in
> commit 0823efedd0fb8669b7e840954bc54c3b2cf08d67 (Subversion r190402).
>
> > --- a/gcc/gengtype-lex.l
> > +++ b/gcc/gengtype-lex.l
> > @@ -108,6 +108,7 @@ EOID [^[:alnum:]_]
> > "enum"/{EOID} { return ENUM; }
> > "ptr_alias"/{EOID} { return PTR_ALIAS; }
> > "nested_ptr"/{EOID} { return NESTED_PTR; }
> > +"user"/{EOID}{ return USER_GTY; }
> > [0-9]+ { return NUM; }
> > "param"[0-9]*"_is"/{EOID} {
> > *yylval = XDUPVAR (const char, yytext, yyleng, yyleng+1);
>
> > --- a/gcc/gengtype-parse.c
> > +++ b/gcc/gengtype-parse.c
> > @@ -499,6 +499,10 @@ option (options_p prev)
> > [...]
>
> > --- a/gcc/gengtype.h
> > +++ b/gcc/gengtype.h
> > @@ -463,6 +463,7 @@ enum
> > ELLIPSIS,
> > PTR_ALIAS,
> > NESTED_PTR,
> > +USER_GTY,
> > PARAM_IS,
> > NUM,
> > SCALAR,
>
> This did add 'USER_GTY' to what nowadays is known as 'enum gty_token',
> but didn't accordingly update 'gcc/gengtype-parse.c:token_names', leaving
> those out of sync. Updating 'gcc/gengtype-parse.c:token_value_format'
> wasn't necessary, as:
>
> /* print_token assumes that any token >= FIRST_TOKEN_WITH_VALUE may have
>a meaningful value to be printed. */
> FIRST_TOKEN_WITH_VALUE = PARAM_IS
>
> This, in turn, got further confused -- or "fixed" -- by later changes:
> 2014 commit 63f5d5b818319129217e41bcb23db53f99ff11b0 (Subversion r218558)
> "remove gengtype support for param_is use_param, if_marked and splay tree
> allocators",
> which reciprocally missed corresponding clean-up.
>
> OK to push the attached
> "GTY: Repair 'enum gty_token', 'token_names' desynchronization"?
OK.
>
> On top of that, I'll then re-submit an adjusted
>
> "GTY: Clean up obsolete parametrized structs remnants".
>
>
> 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
GTY: Repair 'enum gty_token', 'token_names' desynchronization (was: [cxx-conversion] Support garbage-collected C++ templates)
Hi!
On 2012-08-10T11:06:46-0400, Diego Novillo wrote:
> * gengtype-lex.l (USER_GTY): Add pattern for "user".
> * gengtype-parse.c (option): Handle USER_GTY.
> (opts_have): New.
> (type): Call it.
> If the keyword 'user' is used, do not walk the fields
> of the structure.
> * gengtype.h (USER_GTY): Add.
These changes got incorporated in
commit 0823efedd0fb8669b7e840954bc54c3b2cf08d67 (Subversion r190402).
> --- a/gcc/gengtype-lex.l
> +++ b/gcc/gengtype-lex.l
> @@ -108,6 +108,7 @@ EOID [^[:alnum:]_]
> "enum"/{EOID} { return ENUM; }
> "ptr_alias"/{EOID} { return PTR_ALIAS; }
> "nested_ptr"/{EOID} { return NESTED_PTR; }
> +"user"/{EOID}{ return USER_GTY; }
> [0-9]+ { return NUM; }
> "param"[0-9]*"_is"/{EOID} {
> *yylval = XDUPVAR (const char, yytext, yyleng, yyleng+1);
> --- a/gcc/gengtype-parse.c
> +++ b/gcc/gengtype-parse.c
> @@ -499,6 +499,10 @@ option (options_p prev)
> [...]
> --- a/gcc/gengtype.h
> +++ b/gcc/gengtype.h
> @@ -463,6 +463,7 @@ enum
> ELLIPSIS,
> PTR_ALIAS,
> NESTED_PTR,
> +USER_GTY,
> PARAM_IS,
> NUM,
> SCALAR,
This did add 'USER_GTY' to what nowadays is known as 'enum gty_token',
but didn't accordingly update 'gcc/gengtype-parse.c:token_names', leaving
those out of sync. Updating 'gcc/gengtype-parse.c:token_value_format'
wasn't necessary, as:
/* print_token assumes that any token >= FIRST_TOKEN_WITH_VALUE may have
a meaningful value to be printed. */
FIRST_TOKEN_WITH_VALUE = PARAM_IS
This, in turn, got further confused -- or "fixed" -- by later changes:
2014 commit 63f5d5b818319129217e41bcb23db53f99ff11b0 (Subversion r218558)
"remove gengtype support for param_is use_param, if_marked and splay tree
allocators",
which reciprocally missed corresponding clean-up.
OK to push the attached
"GTY: Repair 'enum gty_token', 'token_names' desynchronization"?
On top of that, I'll then re-submit an adjusted
"GTY: Clean up obsolete parametrized structs remnants".
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
>From 8d2b040e825acdcddb7e1ff991fd538db13392f2 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge
Date: Wed, 5 Jul 2023 11:10:55 +0200
Subject: [PATCH] GTY: Repair 'enum gty_token', 'token_names' desynchronization
For example, for the following (made-up) changes:
--- gcc/ggc-tests.cc
+++ gcc/ggc-tests.cc
@@ -258 +258 @@ class GTY((tag("1"))) some_subclass : public example_base
-class GTY((tag("2"))) some_other_subclass : public example_base
+class GTY((tag(user))) some_other_subclass : public example_base
@@ -384 +384 @@ test_chain_next ()
-struct GTY((user)) user_struct
+struct GTY((user user)) user_struct
..., we get unexpected "have a param_is option" diagnostics:
[...]
build/gengtype \
-S [...]/source-gcc/gcc -I gtyp-input.list -w tmp-gtype.state
[...]/source-gcc/gcc/ggc-tests.cc:258: parse error: expected a string constant, have a param_is option
[...]/source-gcc/gcc/ggc-tests.cc:384: parse error: expected ')', have a param_is option
make[2]: *** [Makefile:2888: s-gtype] Error 1
[...]
This traces back to 2012 "Support garbage-collected C++ templates", which got
incorporated in commit 0823efedd0fb8669b7e840954bc54c3b2cf08d67
(Subversion r190402), which did add 'USER_GTY' to what nowadays is known as
'enum gty_token', but didn't accordingly update
'gcc/gengtype-parse.c:token_names', leaving those out of sync. Updating
'gcc/gengtype-parse.c:token_value_format' wasn't necessary, as:
/* print_token assumes that any token >= FIRST_TOKEN_WITH_VALUE may have
a meaningful value to be printed. */
FIRST_TOKEN_WITH_VALUE = PARAM_IS
This, in turn, got further confused -- or "fixed" -- by later changes:
2014 commit 63f5d5b818319129217e41bcb23db53f99ff11b0 (Subversion r218558)
"remove gengtype support for param_is use_param, if_marked and splay tree allocators",
which reciprocally missed corresponding clean-up.
With that addressed via adding the missing '"user"' to 'token_names', and,
until that is properly fixed, a temporary 'UNUSED_PARAM_IS' (re-)added for use
with 'FIRST_TOKEN_WITH_VALUE', we then get the expected:
[...]/source-gcc/gcc/ggc-tests.cc:258: parse error: expected a string constant, have 'user'
[...]/source-gcc/gcc/ggc-tests.cc:384: parse error: expected ')', have 'user'
gcc/
* gengtype-parse.cc (token_names): Add '"user"'.
* gengtype.h (gty_token): Add 'UNUSED_PARAM_IS' for use with
'FIRST_TOKEN_WITH_VALUE'.
---
Re: [cxx-conversion] Support garbage-collected C++ templates
On Sun, Aug 12, 2012 at 11:28 PM, Laurynas Biveinis
laurynas.bivei...@gmail.com wrote:
I'm referring to the very first part of gty.texi, section 22 before
the subsection table of contents:
http://gcc.gnu.org/onlinedocs/gccint/Type-Information.html#Type-Information.
It talks about C, structs and unions and it will need updating about
C++ support in gengtype.
Ah, thanks. I've added this patch to the merge image. I will update
the documentation to include 'class' when I update gengtype later on.
Diego.
diff --git a/gcc/doc/gty.texi b/gcc/doc/gty.texi
index 3754b75..614dae3 100644
--- a/gcc/doc/gty.texi
+++ b/gcc/doc/gty.texi
@@ -13,17 +13,17 @@ involve determining information about GCC's data
structures from GCC's
source code and using this information to perform garbage collection and
implement precompiled headers.
-A full C parser would be too complicated for this task, so a limited
-subset of C is interpreted and special markers are used to determine
-what parts of the source to look at. All @code{struct} and
-@code{union} declarations that define data structures that are
-allocated under control of the garbage collector must be marked. All
-global variables that hold pointers to garbage-collected memory must
-also be marked. Finally, all global variables that need to be saved
-and restored by a precompiled header must be marked. (The precompiled
-header mechanism can only save static variables if they're scalar.
-Complex data structures must be allocated in garbage-collected memory
-to be saved in a precompiled header.)
+A full C++ parser would be too complicated for this task, so a limited
+subset of C++ is interpreted and special markers are used to determine
+what parts of the source to look at. All @code{struct}, @code{union}
+and @code{template} structure declarations that define data structures
+that are allocated under control of the garbage collector must be
+marked. All global variables that hold pointers to garbage-collected
+memory must also be marked. Finally, all global variables that need
+to be saved and restored by a precompiled header must be marked. (The
+precompiled header mechanism can only save static variables if they're
+scalar. Complex data structures must be allocated in garbage-collected
+memory to be saved in a precompiled header.)
The full format of a marker is
@smallexample
Re: [cxx-conversion] Support garbage-collected C++ templates
Diego - * doc/gty.texi: Document support for C++ templates and user-provided markers. The 1st node in this doc file needs s/C/C++/g and perhaps some more explanation with an eye on C++. Sorry. I'm not sure what you are trying to say here. I'm referring to the very first part of gty.texi, section 22 before the subsection table of contents: http://gcc.gnu.org/onlinedocs/gccint/Type-Information.html#Type-Information. It talks about C, structs and unions and it will need updating about C++ support in gengtype. -- Laurynas
Re: [cxx-conversion] Support garbage-collected C++ templates
On 12-08-09 03:12 , Laurynas Biveinis wrote:
Might be also interesting to try valgrind. Good to hear the zone
collector hasn't bitrotten once again.
Well, it seems it has now. I just tried --with-gc=zone in trunk and it
failed. I have not merged trunk for 2-3 weeks, so something may have
broken it in the meantime.
* doc/gty.texi: Document support for C++ templates and
user-provided markers.
The 1st node in this doc file needs s/C/C++/g and perhaps some more
explanation with an eye on C++.
Sorry. I'm not sure what you are trying to say here. I'm adding more
details on the user-provided GTY keyword below.
Diego.
diff --git a/gcc/doc/gty.texi b/gcc/doc/gty.texi
index 472738e..2210441 100644
--- a/gcc/doc/gty.texi
+++ b/gcc/doc/gty.texi
@@ -68,6 +68,7 @@ These don't need to be marked.
@menu
* GTY Options:: What goes inside a @code{GTY(())}.
* GGC Roots:: Making global variables GGC roots.
+* User GC::Adding user-provided GC marking routines.
* Files:: How the generated files work.
* Invoking the garbage collector:: How to invoke the garbage collector.
* Troubleshooting:: When something does not work as expected.
@@ -435,20 +436,53 @@ The @code{special} option is used to mark types
that have to be dealt
with by special case machinery. The parameter is the name of the
special case. See @file{gengtype.c} for further details. Avoid
adding new special cases unless there is no other alternative.
+
+@findex user
+@item user
+
+The @code{user} option indicates that the code to mark structure
+fields is completely handled by user-provided routines. Section
+@ref{User GC} for details on what functions need to be provided.
@end table
+@node User GC
@section Support for user-provided GC marking routines
+@cindex user gc
The garbage collector supports types for which no automatic marking
code is generated. For these types, the user is required to provide
four functions: one to act as a marker for garbage collection, and
-three functions to act as marker and pointer walking for pre-compiled
+two functions to act as marker and pointer walking for pre-compiled
headers.
-User-provided types are currently supported for C++ template
-structures. When a template type @code{TP} is marked with @code{GTY},
-all instances of that type are considered user-provided types. As
-such, the user needs to provide template functions to mark all the
-fields of the type.
+Given a structure @code{struct GTY((user)) my_struct}, the following
functions
+should be defined to mark @code{my_struct}
+
+@smallexample
+void gt_ggc_mx (my_struct *p)
+@{
+ /* This marks field 'fld'. */
+ gt_ggc_mx (p-fld);
+@}
+
+void gt_pch_nx (my_struct *p)
+@{
+ /* This marks field 'fld'. */
+ gt_pch_nx (tp-fld);
+@}
+
+void gt_pch_nx (my_struct *p, gt_pointer_operator op, void *cookie)
+@{
+ /* For every field 'fld', call the given pointer operator. */
+ op ((tp-fld), cookie);
+@}
+@end smallexample
+
+@section User-provided marking routines for template types
+When a template type @code{TP} is marked with @code{GTY}, all
+instances of that type are considered user-provided types. This means
+that the individual instances of @code{TP} do not need to marked with
+@code{GTY}. The user needs to provide template functions to mark all
+the fields of the type.
The following code snippets represent all the functions that need to
be provided. Note that type @code{TP} may reference to more than one
@@ -509,8 +543,6 @@ will, in turn, walk all the pointers inside fields
of @code{T}).
In the case of @code{TPT *}, references to @code{T *} must be
handled by calling the @code{op} function on the address of the
pointer (see the code snippets above).
-
-@item Only template structures are supported at this time.
@end enumerate
@node GGC Roots
Re: [cxx-conversion] Support garbage-collected C++ templates
On 2012-08-10 08:06, Diego Novillo wrote: The end point should be that the only thing we really need to tell gengtype about are the variable roots. Everything else would rely on user-provided markings. I suppose we could still keep the automatic option for really simple stuff, though. Yes please. Markup may be awkward, but I think can be less awkward than generating those three cookie-cutter functions. r~
Re: [cxx-conversion] Support garbage-collected C++ templates
On 12-08-10 16:14 , Richard Henderson wrote: On 2012-08-10 08:06, Diego Novillo wrote: The end point should be that the only thing we really need to tell gengtype about are the variable roots. Everything else would rely on user-provided markings. I suppose we could still keep the automatic option for really simple stuff, though. Yes please. Markup may be awkward, but I think can be less awkward than generating those three cookie-cutter functions. Yeah. Another thing I suppose we want to keep is the whole 'prev' and 'next' markings. These generate harness that would be cumbersome to implement from user code. Diego.
Re: [cxx-conversion] Support garbage-collected C++ templates
On 8/10/12, Diego Novillo dnovi...@google.com wrote: On 12-08-10 16:14 , Richard Henderson wrote: On 2012-08-10 08:06, Diego Novillo wrote: The end point should be that the only thing we really need to tell gengtype about are the variable roots. Everything else would rely on user-provided markings. I suppose we could still keep the automatic option for really simple stuff, though. Yes please. Markup may be awkward, but I think can be less awkward than generating those three cookie-cutter functions. Yeah. Another thing I suppose we want to keep is the whole 'prev' and 'next' markings. These generate harness that would be cumbersome to implement from user code. Diego and I talked about this issue. What follows is sort of a brain dump. Corrections welcome. There are several principles we can apply to the work. Data types that change frequently should be handled automatically. Otherwise, the purpose of precise garbage collection is somewhat defeated. If we get to that situation, we should simply figure out how to convert the collector to something else. GTY markings that change frequently, or are hard to understand and get right, are a burden as well. The complexity of gengtype's implementation can be substantially reduced if it does not try to solve all problems. We are compiler engineers, and we can do complex manual work when appropriate. Not everything needs to be automatic. Applying those principles, we can reach some conclusions about approach. We can rely on GTY((user)) for template class types. By and large these types implement general data structures, like hash tables. The won't change much once built, and so maintenance of the manual marking routines will not be a large burden. Taking this approach means that gengtype will not have to understand templates. We really do not want gengtype trying to understand templates. Diego has already implemented this part. Some types generic via void* and use param_is/use_param. As we migrate to templates, much of these uses can go away. Perhaps, eventually, we might be able to remove that complexity from gengtype. As this possibility is closer to wishful thinking, it has really low priority. We cannot rely on GTY((user)) for class hierarchies that hold program structures. For example, cgraph and tree nodes are too volatile to rely on manually synchronizing the marker function with the data fields. So, we need to get gengtype to work with class hierarchies. We probably do not need to handle multiple inheritance. First, existing structures do not use it. Second, it probably would not be used much anyway. Polymorphic class hierarchies may require the user to add a couple of method declarations for gengtype. Gengtype would then provide the method definitions. We do not have any polymorphic classes yet, so this issue has a low priority. We will likely borrow the descriminator/tag structure of unions for the marking of non-polymorphic class hierarchies. Gengtype will split the marking of fields and the identification of the dynamic type into separate functions. We have several non-polymorphic class hierarchies now, though represented with unions and embedding, so this issue has a high priority. Some current classes with nested unions, e.g. tree_type_symtab within tree_type_common within tree_node, might be convertable to a class hierarchy that eliminates all unions. If so, they will likely need more than one descriminator. Given that such structures can persist with nested unions for some time, this issue has low priority. Given all that, it seems that the highest priority for gengtype modifications is direct support for non-polymorphic single-inheritance class hierarchies that are discriminated by tags. -- Lawrence Crowl
Re: [cxx-conversion] Support garbage-collected C++ templates
Diego - It's all good changes and your plan for future improvements sounds good, including the part where gengtype is killed with fire. - Functions should be emitted in files that have access to the structure where they were defined. I'm not convinced that the current multiplicity of gt-*.[ch] files is even necessary. However, I would like the guidance of a gengtype maintainer. I don't think I fully understand all of it. Yes, I remember looking into splitting the output a few years ago. It should be possible to split gtype-desc.h into header files to be included in source header files defining the relevant types. I.e. tree.h includes a generated gt-tree.h that provides allocator definitions for the tree.h types. gtype-desc.h then would be left with the master enum of all GTY-handled types. It should be also possible to split gtype-desc.c into already-existing gt-foo.h too, although the benefit of doing that is not as big I think. I've tested the patch on x86_64 with the page and zone collectors and with --enable-checking=gc,gcac (boy was that a slow mistake). Might be also interesting to try valgrind. Good to hear the zone collector hasn't bitrotten once again. * doc/gty.texi: Document support for C++ templates and user-provided markers. The 1st node in this doc file needs s/C/C++/g and perhaps some more explanation with an eye on C++. -- Laurynas
Re: [cxx-conversion] Support garbage-collected C++ templates
On Wed, Aug 8, 2012 at 11:27 PM, Diego Novillo dnovi...@google.com wrote: On 12-08-08 17:25 , Gabriel Dos Reis wrote: Aha, so it is an ordering issue, e.g. declarations being generated after they have been seen used in an instantiation. We might want to consider including the header file (that contains only the declarations of the marking functions) in the header files that contain the GTY-marked type definition. In this case, it would be included near the end of tree.h Right. And that's the part of my plan that requires killing gengtype with fire first. When I started down that path, it became a very messy re-write, so I decided it was better to do it in stages. But now with doing it in stages you end up with (this) first stage that complicates gengtype to support a very small subset of C++ types (namely the one special case you need for vec.h). Exactly what I did _not_ want! I understood that you had the complete killing of gengtype with fire ready (or almost ready). Please finish it instead. Thanks, Richard. Diego.
Re: [cxx-conversion] Support garbage-collected C++ templates
On Thu, Aug 9, 2012 at 5:03 AM, Richard Guenther richard.guent...@gmail.com wrote: But now with doing it in stages you end up with (this) first stage that complicates gengtype to support a very small subset of C++ types (namely the one special case you need for vec.h). Exactly what I did _not_ want! No. It supports all C++ types. All it needs is the user annotation. I understood that you had the complete killing of gengtype with fire ready (or almost ready). Please finish it instead. No. It was not even close. The full re-write will wait until the branch is merged in trunk. It will touch too many files and the branch is already hard to maintain as it is. Adding support for explicit user annotations is easy enough. Patch coming up. Diego.
Re: [cxx-conversion] Support garbage-collected C++ templates
On Thu, Aug 9, 2012 at 2:44 PM, Diego Novillo dnovi...@google.com wrote: On Thu, Aug 9, 2012 at 5:03 AM, Richard Guenther richard.guent...@gmail.com wrote: But now with doing it in stages you end up with (this) first stage that complicates gengtype to support a very small subset of C++ types (namely the one special case you need for vec.h). Exactly what I did _not_ want! No. It supports all C++ types. All it needs is the user annotation. You said it only works for types in the template parameter list and there you only support types (and not integers). Which means I fail to see how it works for VEC(tree). As far as I understand you are not creating the gt_pch_nx overloads for all GTYed types (which includes 'tree'). If you do then I fail to see why it should be restricted at all? I understood that you had the complete killing of gengtype with fire ready (or almost ready). Please finish it instead. No. It was not even close. The full re-write will wait until the branch is merged in trunk. It will touch too many files and the branch is already hard to maintain as it is. Well. So what are exactly the limitations? If I can provide user-defined gc routines for all C++ types and gengtype will pick them up automagically when auto-generating gc routines for other types then fine. What I do not understand is why you need a GTY(()) annotation on C++ types with user-defined gc routines. gengtype should treat all types not marked with GTY(()) as having user-defined gc routines, no? Richard. Adding support for explicit user annotations is easy enough. Patch coming up. Diego.
Re: [cxx-conversion] Support garbage-collected C++ templates
hi Diego,
just a word on style in the documentation:
+templatetypename T
+void gt_pch_nx (TPT *tp)
+@{
+ extern void gt_pch_nx (T);
+
+ /* This marks field 'fld' of type 'T'. */
+ gt_pch_nx (tp-fld);
+@}
'extern' declaration at local scope if considered an extremely
poor style in C++. Furthermore, it does not interact
well with template instantiations and scope rules; plus
it does not work well when the function actually has an
internal linkage.
A proper way to bring a symbol into local scope is through
a using-declaration:
using ::gt_pch_nx;
-- Gaby
Re: [cxx-conversion] Support garbage-collected C++ templates
On 12-08-08 16:12 , Gabriel Dos Reis wrote:
hi Diego,
just a word on style in the documentation:
+templatetypename T
+void gt_pch_nx (TPT *tp)
+@{
+ extern void gt_pch_nx (T);
+
+ /* This marks field 'fld' of type 'T'. */
+ gt_pch_nx (tp-fld);
+@}
'extern' declaration at local scope if considered an extremely
poor style in C++. Furthermore, it does not interact
well with template instantiations and scope rules; plus
it does not work well when the function actually has an
internal linkage.
A proper way to bring a symbol into local scope is through
a using-declaration:
using ::gt_pch_nx;
I struggled a bit with this. I need to tell the template function that
there exists a free function gt_pch_nx that takes a T. This is not
something that any header file has at the point of this declaration.
The function gt_pch_nx(T) is declared and defined later in one of the
gt-*.h files. This is another problem with the way that gengtype works
today.
The using-declaration that you propose does not seem to give me what I
want, though. How does it know that the function takes a T?
Diego.
Re: [cxx-conversion] Support garbage-collected C++ templates
On Wed, Aug 8, 2012 at 3:37 PM, Diego Novillo dnovi...@google.com wrote:
On 12-08-08 16:12 , Gabriel Dos Reis wrote:
hi Diego,
just a word on style in the documentation:
+templatetypename T
+void gt_pch_nx (TPT *tp)
+@{
+ extern void gt_pch_nx (T);
+
+ /* This marks field 'fld' of type 'T'. */
+ gt_pch_nx (tp-fld);
+@}
'extern' declaration at local scope if considered an extremely
poor style in C++. Furthermore, it does not interact
well with template instantiations and scope rules; plus
it does not work well when the function actually has an
internal linkage.
A proper way to bring a symbol into local scope is through
a using-declaration:
using ::gt_pch_nx;
I struggled a bit with this. I need to tell the template function that there
exists a free function gt_pch_nx that takes a T. This is not something that
any header file has at the point of this declaration.
The function gt_pch_nx(T) is declared and defined later in one of the
gt-*.h files. This is another problem with the way that gengtype works
today.
The using-declaration that you propose does not seem to give me what I want,
though. How does it know that the function takes a T?
So, if the issue that the function does not exist at the point of the template
definition, but will definitely exist at the point where it is instantiated
because of inclusion of a header file (later or in a different
translation unit),
then the usual way is to write no declaration at all. The compiler will perform
a lookup at the point of instantiation and resolve the name
appropriate, or error.
you can just write:
void gt_pch_nx (TPT *tp)
{
/* This marks field 'fld' of type 'T'. */
gt_pch_nx (tp-fld);
}
Am I understanding you correctly?
-- Gaby
Re: [cxx-conversion] Support garbage-collected C++ templates
On Wed, Aug 8, 2012 at 4:47 PM, Gabriel Dos Reis
g...@integrable-solutions.net wrote:
So, if the issue that the function does not exist at the point of the template
definition, but will definitely exist at the point where it is instantiated
because of inclusion of a header file (later or in a different
translation unit),
then the usual way is to write no declaration at all. The compiler will
perform
a lookup at the point of instantiation and resolve the name
appropriate, or error.
you can just write:
void gt_pch_nx (TPT *tp)
{
/* This marks field 'fld' of type 'T'. */
gt_pch_nx (tp-fld);
}
Oh, but if I do that I get the error
In file included from tree.h:29:0,
from cp/tree.c:28:
vec.h: In instantiation of 'void gt_ggc_mx(vec_tT*) [with T = tree_node*]':
./gt-cp-tree.h:571:59: required from here
vec.h:180:5: error: no matching function for call to 'gt_ggc_mx(tree_node*)'
gt_ggc_mx (v-vec[i]);
^
Because no declaration for gt_ggc_mx(tree_node *) exists at that
point. It will exist in some other header file that's been generated
by gengtype (which is included at the *end* of the .c file).
Diego.
Re: [cxx-conversion] Support garbage-collected C++ templates
On Wed, Aug 8, 2012 at 3:58 PM, Diego Novillo dnovi...@google.com wrote:
On Wed, Aug 8, 2012 at 4:47 PM, Gabriel Dos Reis
g...@integrable-solutions.net wrote:
So, if the issue that the function does not exist at the point of the
template
definition, but will definitely exist at the point where it is instantiated
because of inclusion of a header file (later or in a different
translation unit),
then the usual way is to write no declaration at all. The compiler will
perform
a lookup at the point of instantiation and resolve the name
appropriate, or error.
you can just write:
void gt_pch_nx (TPT *tp)
{
/* This marks field 'fld' of type 'T'. */
gt_pch_nx (tp-fld);
}
Oh, but if I do that I get the error
In file included from tree.h:29:0,
from cp/tree.c:28:
vec.h: In instantiation of 'void gt_ggc_mx(vec_tT*) [with T = tree_node*]':
./gt-cp-tree.h:571:59: required from here
vec.h:180:5: error: no matching function for call to 'gt_ggc_mx(tree_node*)'
gt_ggc_mx (v-vec[i]);
^
Because no declaration for gt_ggc_mx(tree_node *) exists at that
point. It will exist in some other header file that's been generated
by gengtype (which is included at the *end* of the .c file).
Aha, so it is an ordering issue, e.g. declarations being generated
after they have been seen used in an instantiation.
We might want to consider including the header file (that contains
only the declarations of the marking functions) in the header
files that contain the GTY-marked type definition. In this case, it would
be included near the end of tree.h
-- Gaby
Re: [cxx-conversion] Support garbage-collected C++ templates
On 12-08-08 17:25 , Gabriel Dos Reis wrote: Aha, so it is an ordering issue, e.g. declarations being generated after they have been seen used in an instantiation. We might want to consider including the header file (that contains only the declarations of the marking functions) in the header files that contain the GTY-marked type definition. In this case, it would be included near the end of tree.h Right. And that's the part of my plan that requires killing gengtype with fire first. When I started down that path, it became a very messy re-write, so I decided it was better to do it in stages. Diego.
Re: [cxx-conversion] Support garbage-collected C++ templates
On Wed, Aug 8, 2012 at 4:27 PM, Diego Novillo dnovi...@google.com wrote: On 12-08-08 17:25 , Gabriel Dos Reis wrote: Aha, so it is an ordering issue, e.g. declarations being generated after they have been seen used in an instantiation. We might want to consider including the header file (that contains only the declarations of the marking functions) in the header files that contain the GTY-marked type definition. In this case, it would be included near the end of tree.h Right. And that's the part of my plan that requires killing gengtype with fire first. When I started down that path, it became a very messy re-write, so I decided it was better to do it in stages. Aha, thanks. (I am slowly catching up.) -- Gaby
