[C++] Move FINAL flag to middle-end trees.

> 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?

I have run across the following testcase:
namespace {
class A {
public:
  virtual int foo(void)
{
  return 0;
}
};
}
class A *b;
main()
{
  return b->foo();
}

here I now can devirtualize b->foo into A because A is in anonymous namespace.
We however won't remove b because it is externally visible.  Is it valid to
bring b local based on fact that A is anonymous and thus no valid C++ program
can read it?

The pointer type probably isn't anonymous anymore?

Honza

	* cp-tree.h (struct lang_type_class): Free is_final bit.
	 (CLASSTYPE_FINAL): Define using BINFO_FINAL_P.
	(DECL_FINAL_P): Remove.
	* pt.c (instantiate_class_template_1): Guard CLASSTYPE_FINAL
	by CLASS_TYPE_P
	* tree.h (tree_base): Add BINFO_FINAL_P docs
	(BINFO_FINAL_P): Define.
	(tree_decl_with_vis): One bit is taken for FINAL.
	(DECL_FINAL_P): New.

> 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 visibility for template arguments.  */
>        determine_visibility (TYPE_MAIN_DECL (type));
>      }
> -  CLASSTYPE_FINAL (type) = CLASSTYPE_FINAL (pattern);
> +  if (CLASS_TYPE_P (type))
> +    CLASSTYPE_FINAL (type) = CLASSTYPE_FINAL (pattern);

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?

Honza

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 type.

> here I now can devirtualize b->foo into A because A is in anonymous namespace.
> We however won't remove b because it is externally visible.  Is it valid to
> bring b local based on fact that A is anonymous and thus no valid C++ program
> can read it?

Hmm, determine_visibility ought to be doing that already.

Jason

> 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 type.

OK, I mostly need the flag on type anyway, so it will save some indirection.  I will
re-test and commit the variant using default_def flag of type.

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 guess I can just disable FUNCTION_DECL checking on this macro in middle-end,
but I do not like it much.  Or I can have same C++ FE macros using the same
flag that also allow templates, but then we can get them out of sync.  Or I can
update 100+ places in C++ FE to use different macro on template or I can
introduce SET variant that will care about decl type or I can just have two
flags and make C++ FE to mirror DECL_CONSTRUCTOR_P into the middle end flag?

Any more resonable options?
> 
> >here I now can devirtualize b->foo into A because A is in anonymous namespace.
> >We however won't remove b because it is externally visible.  Is it valid to
> >bring b local based on fact that A is anonymous and thus no valid C++ program
> >can read it?
> 
> Hmm, determine_visibility ought to be doing that already.

You are right.  I simplified the testcase from code I looked at but probably I
overlooked something.  Sorry for the noise!

Honza

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 fix the front end to use STRIP_TEMPLATE to make sure we're 
checking/setting the flag on a FUNCTION_DECL.

Jason