This is the mail archive of the
mailing list for the GCC project.
Re: [RFA] Type inheritance graph analysis & speculative devirtualization, part 4/7, ODR at LTO time
- From: Jason Merrill <jason at redhat dot com>
- To: Jan Hubicka <hubicka at ucw dot cz>, gcc-patches at gcc dot gnu dot org, marxin dot liska at gmail dot com, rguenther at suse dot de, mjambor at suse dot cz, davidxl at google dot com
- Date: Sun, 01 Sep 2013 15:34:56 -0400
- Subject: Re: [RFA] Type inheritance graph analysis & speculative devirtualization, part 4/7, ODR at LTO time
- Authentication-results: sourceware.org; auth=none
- References: <20130819140116 dot GA16575 at kam dot mff dot cuni dot cz>
On 08/19/2013 10:01 AM, Jan Hubicka wrote:
+ /* All equivalent types, if more than one. */
+ vec<tree, va_gc> *types;
+ /* Set of all equivalent types, if NON-NULL. */
+ pointer_set_t * GTY((skip)) types_set;
Why do you need both a vector and a pointer set? Can't you drop the
vector and use pointer_set_traverse for operating on each of the elements?
+ "type %qD violate one definition rule ",
+ "the type of same name with different memory layout "
+ "defined in other compilation unit");
Is there any way to identify which TUs the definitions come from?
I would adjust the wording to
"a type with the same name but different layout is defined in another
+ "the inconsistent type of same name with different bases"
+ " (defined in other compilation unit)");
and "a type with the same name but different base classes is defined in
another translation unit"
+ /* When assembler name of virtual table is available, it is
+ easy to compare types for equivalence.
+ FIXME: the code comparing type names consider all instantiations of the
+ same template to have same name. This is because we have no access
+ to template parameters. For types with no virtual method tables
+ we thus can return false positives. At the moment we do not need
+ to compare types in other scenarios than devirtualization. */
This FIXME doesn't seem to apply to the case where we're comparing the
vtable mangled names, so it should move later in the function.
OK with the diagnostic/comment issues fixed.
BTW, if anything asks for the DECL_ASSEMBLER_NAME of the TYPE_NAME, it
will get an ODR-unique mangled name for the type. But we don't
currently set that during normal compilation because it isn't used in
mangling of actual symbols.