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):
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
19 matches
Mail list logo
