This is the mail archive of the
mailing list for the GCC project.
Re: [C++ patch] Move FINAL flag to middle-end trees.
- From: Jan Hubicka <hubicka at ucw dot cz>
- To: Jason Merrill <jason at redhat dot com>
- Cc: Jan Hubicka <hubicka at ucw dot cz>, gcc-patches at gcc dot gnu dot org
- Date: Sat, 24 Aug 2013 11:18:11 +0200
- Subject: Re: [C++ patch] Move FINAL flag to middle-end trees.
- References: <20130822095937 dot GF16124 at kam dot mff dot cuni dot cz> <52162B9B dot 5060905 at redhat dot com> <20130822152254 dot GC19256 at kam dot mff dot cuni dot cz> <521769A8 dot 3010204 at redhat dot com> <20130823135755 dot GB22972 at kam dot mff dot cuni dot cz> <521770DA dot 300 at redhat dot com> <20130823143616 dot GA27462 at kam dot mff dot cuni dot cz> <20130823145112 dot GC27462 at kam dot mff dot cuni dot cz> <52184F67 dot 3020908 at redhat dot com>
> 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!