On Sun, Aug 12, 2012 at 11:28 PM, Laurynas Biveinis
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 ne
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
On 8/10/12, Diego Novillo 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 mar
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
opt
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.
Ye
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
bro
On 12-08-09 09:05 , Richard Guenther wrote:
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?
Ideally, yes. But currently gengtype makes it
On Thu, Aug 9, 2012 at 2:44 PM, Diego Novillo wrote:
> On Thu, Aug 9, 2012 at 5:03 AM, Richard Guenther
> 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
On Thu, Aug 9, 2012 at 5:03 AM, Richard Guenther
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 suppor
On Wed, Aug 8, 2012 at 11:27 PM, Diego Novillo 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 contai
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 g
On Wed, Aug 8, 2012 at 4:27 PM, Diego Novillo 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 contain
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
f
On Wed, Aug 8, 2012 at 3:58 PM, Diego Novillo wrote:
> On Wed, Aug 8, 2012 at 4:47 PM, Gabriel Dos Reis
> 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 inc
On Wed, Aug 8, 2012 at 4:47 PM, Gabriel Dos Reis
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 uni
On Wed, Aug 8, 2012 at 3:37 PM, Diego Novillo wrote:
> On 12-08-08 16:12 , Gabriel Dos Reis wrote:
>>
>> hi Diego,
>>
>> just a word on style in the documentation:
>>
>>> +template
>>> +void gt_pch_nx (TP *tp)
>>> +@{
>>> + extern void gt_pch_nx (T&);
>>> +
>>> + /* This marks field 'fld' of typ
On 12-08-08 16:12 , Gabriel Dos Reis wrote:
hi Diego,
just a word on style in the documentation:
+template
+void gt_pch_nx (TP *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 considere
hi Diego,
just a word on style in the documentation:
> +template
> +void gt_pch_nx (TP *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++
18 matches
Mail list logo
