OK.
Jason
> Naming suggestion: we already use cpp_ as prefix for the C preprocessor.
> Could we please not use it for C++, given that tree is used by so
> many clients for just about anything. cxx_ is a good alternative.
CXX is fine with me. I updated by local copy.
Honza
>
> > unsigned final : 1;
>
On Sun, Aug 25, 2013 at 10:38 AM, Jan Hubicka wrote:
>> On 08/24/2013 05:18 AM, Jan Hubicka wrote:
>> >In the next step I would like to introduce the
>> >DECL_CPP_CONSTRUCTOR/DESTRUCTOR macro.
>> >The catch I run into is that these flags are tested on TEMPLATE_DECL so the
>> >middle-end
>> >macr
> On 08/24/2013 05:18 AM, Jan Hubicka wrote:
> >In the next step I would like to introduce the
> >DECL_CPP_CONSTRUCTOR/DESTRUCTOR macro.
> >The catch I run into is that these flags are tested on TEMPLATE_DECL so the
> >middle-end
> >macro bombs on type checking. I wonder what is best approach he
On 08/24/2013 05:18 AM, Jan Hubicka wrote:
In the next step I would like to introduce the DECL_CPP_CONSTRUCTOR/DESTRUCTOR
macro.
The catch I run into is that these flags are tested on TEMPLATE_DECL so the
middle-end
macro bombs on type checking. I wonder what is best approach here.
I think f
> On 08/23/2013 10:51 AM, Jan Hubicka wrote:
> >Sadly we ICE here because BINFO of type is not built yet.
> >I tried to move the code after xref_binfos and it does seem to lead to errors
> >while building libstdc++ PCH. Any idea what to do here?
>
> If it's causing trouble, let's just put the fla
On 08/23/2013 10:51 AM, Jan Hubicka wrote:
Sadly we ICE here because BINFO of type is not built yet.
I tried to move the code after xref_binfos and it does seem to lead to errors
while building libstdc++ PCH. Any idea what to do here?
If it's causing trouble, let's just put the flag on the typ
> Hi,
> this is patch I am testing. Does it look OK?
> Index: cp/pt.c
> ===
> --- cp/pt.c (revision 201910)
> +++ cp/pt.c (working copy)
> @@ -8730,7 +8730,8 @@ instantiate_class_template_1 (tree type)
>/* Adjust visibilit
> On 08/23/2013 09:57 AM, Jan Hubicka wrote:
> >Ok, I will prepare variant using public_flag of BINFO that seeems unused.
> >I.e. having BINFO_FINAL_P and C++ specific macro
> >CLASSTYPE_FINAL(t) as BINFO_FINAL_P (TYPE_BINFO (t)).
>
> Sounds good.
Hi,
this is patch I am testing. Does it look OK?
On 08/23/2013 09:57 AM, Jan Hubicka wrote:
Ok, I will prepare variant using public_flag of BINFO that seeems unused.
I.e. having BINFO_FINAL_P and C++ specific macro
CLASSTYPE_FINAL(t) as BINFO_FINAL_P (TYPE_BINFO (t)).
Sounds good.
Jason
On 08/23/2013 03:47 PM, Jason Merrill wrote:
On 08/22/2013 12:05 PM, Paolo Carlini wrote:
Sorry if I'm saying something rather vague: I suppose you mean
BINFO_FLAG_6? Because it's the last one.
No, that's a language-specific flag.
Ah great. Thanks!
Paolo.
> On 08/22/2013 11:22 AM, Jan Hubicka wrote:
> >This option did not occured to me and of course I would be bit fearing of
> >C++ FE
> >not having binfos ready all the time it wants to touch the type. But
> >probably
> >you know if that can happen ;)
>
> Classes (including struct and union) alwa
On 08/22/2013 11:22 AM, Jan Hubicka wrote:
This option did not occured to me and of course I would be bit fearing of C++ FE
not having binfos ready all the time it wants to touch the type. But probably
you know if that can happen ;)
Classes (including struct and union) always have binfos.
Jas
On 08/22/2013 12:05 PM, Paolo Carlini wrote:
Sorry if I'm saying something rather vague: I suppose you mean
BINFO_FLAG_6? Because it's the last one.
No, that's a language-specific flag.
Jason
Hi,
On 08/22/2013 05:22 PM, Jan Hubicka wrote:
On 08/22/2013 05:59 AM, Jan Hubicka wrote:
+/* Nonzero if RECORD_TYPE represents a final derivation of class. */
+#define TYPE_FINAL_P(NODE) \
+ (RECORD_OR_UNION_CHECK (NODE)->base.default_def_flag)
How about if we put this flag on the BINFO rat
> On 08/22/2013 05:59 AM, Jan Hubicka wrote:
> >+/* Nonzero if RECORD_TYPE represents a final derivation of class. */
> >+#define TYPE_FINAL_P(NODE) \
> >+ (RECORD_OR_UNION_CHECK (NODE)->base.default_def_flag)
>
> How about if we put this flag on the BINFO rather than the type itself?
No problem
On 08/22/2013 05:59 AM, Jan Hubicka wrote:
+/* Nonzero if RECORD_TYPE represents a final derivation of class. */
+#define TYPE_FINAL_P(NODE) \
+ (RECORD_OR_UNION_CHECK (NODE)->base.default_def_flag)
How about if we put this flag on the BINFO rather than the type itself?
Jason
17 matches
Mail list logo
